Jump to content

Attila Bakos

Members
  • Posts

    419
  • Joined

  • Last visited

Posts posted by Attila Bakos

  1. To me this seems to be the exact same issue as the one described in the video, but with different matrices. There are 3 matrices to go from YUV (YCbCr to be technically correct) to RGB. For SD usually the BT.601 matrix is used, for HD the BT.709 matrix, and there's the BT.2020 matrix which you can see in HLG for example. That doesn't mean that you can't encode an UHD resolution log format with the BT.601 matrix, Fuji does just that. And as androidlad mentioned, you can have Alexa log encoded with the BT.709 matrix. To have the right colors in RGB, you have to use the correct matrix. Then you can delog your footage and convert color space etc. But all this comes after the YUV->RGB conversion.

  2. 20 minutes ago, androidlad said:

    Yes, doesn't matter for post-production. We use HLG as an alternative log profile.

    BT.2020 matrix coefficients tag is required for HDR playback, or on-the-fly conversion for SDR playback.

    This is why in Scratch, X-T3 HLG files are default blown-out (on an SDR display) because Scratch respects the tags. If we change the decoding parameter to BT.709 SDR, the images return to the flat look as seen on camera.

    Premiere ignores the tags and decodes everything in BT.709, so HLG files have that flat look ready for grading.

    Respecting or disrespecting the matrix coefficients tag won't result in blown-out footage. I believe you're talking about transfer characteristics, which is basicly the linearization function.
    Disrespecting the matrix coefficients tag will result in different colors, as you have seen in my video.

    I can show you what I mean. This is from a HLG video using the BT.709 matrix, extracted with FFMPEG. (Resolve has the same colors, I checked it.)

    bt709.thumb.jpg.f534ffc725bdbca150f4b747658d2b3d.jpg

     

    This is the same frame using the BT.2020 matrix, this is actually how FFMPEG extracts the frame without any extra options, since it respects the tags by default. But I also used zscale to do the scaling manually and the results are identical to what FFMPEG does by default:

    bt2020.thumb.jpg.4e96b6bab418f3daf75b1cc105096990.jpg

     

    Open the files in different tabs and switch between them. You might say that this doesn't matter to you, but the difference is there.

  3. 1 hour ago, androidlad said:

    Also it's not really a problem for external ProRes for HLG to contain all BT.709 tags. HLG/BT.2020 tags are required for instant HDR playback on end user devices, or for automatic HDR to SDR conversion. Doesn't matter for post-production. Alexa Log-C ProRes carry all BT.709 tags as well, ARRI has to put additional metadata field to say it's Log C.

    There is a matrix in the ITU-R BT.2020 specification that's different from BT.709 and BT.601. If that doesn't matter, then this whole topic is meaningless :)

  4. Just now, Llaasseerr said:

    I haven't been able to get the externally recorded files to match using CST nodes so far, even though the transform spaces are all common types. It seems better to get it right at a metadata tag level if the Atomos supports that. To be honest I'm okay recording h.265 for now because I'm looking at a 2k finish, so the extra chroma information in the ProRes is less useful. But I'd like to sort out why I'm not getting full range h.265 into Resolve all of a sudden.

    I didn't test HLG but if your issue with externally recorded files is metadata only, ffmpeg can change tags without re-encoding using the bitstream filter. I can help you with that if needed.

  5. On 4/19/2019 at 3:10 PM, thephoenix said:

    any shifting in hlg ?

    i record botj internal and external in hlg and same color, actualy maybe more about saturation, and exposure difference between internal and external

    Sorry I couldn't test HLG yet, the only external recordings I got are not HLG.

    Something interesting: with the help of @Papiskokuji and a friend of mine I did some tests with Sony footage coming from two different Sony bodies, and it seems the files require the BT.601 matrix as well, but they are not even flagged. In Resolve all files look off, in Premiere some are okay, some are not. More testing is needed, but I'm surprised I don't see topics or videos about this.

  6. 4 minutes ago, androidlad said:

    Controlling camera parameters and most importantly, pulling focus on Fuji native lenses via USB, require some complicated "reverse engineering".

    Interestingly, a Timelapse tool VIEW did it a few months ago:

    https://www.newsshooter.com/2018/12/24/timelapse-view-intervalometer-is-now-compatible-with-fujifilm-x-series-cameras/

    It allows full control over most Fuji X cameras.

    The developer of libgphoto2 also did it sometime last year, I haven't checked it though: http://www.gphoto.org/proj/libgphoto2/support.php

  7. 3 minutes ago, Mark Romero 2 said:

    Is it the BT.601 tag that is causing the Magenta skies / clouds?

     

    Is there a summary of the various workarounds?

    No, the magenta issue is something else, but I wouldn't worry about it too much. It's not something you see in each clip, I haven't seen it on my X-T3 yet.

    For the workarounds check this thread:

     

     

  8. 1 hour ago, heart0less said:

    Did anyone notice any performance issues in 16 compared to 15.3.1?

    I'm getting this pop-up every now and then, which never bothered me before:

    obraz.png.8ef6399e9318740e015ff68a15b4df06.png

     

    I'm not doing anything crazy - just color grading 8 bit H264 video files from my Panasonic G85 in a 2560x1280 timeline.
    Four nodes, no denoising, no sharpening, no qualifiers.

    There's a thread about it here: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=88961

    Make sure you're updated to the latest drivers.

  9. Did some tests, inside and outside, couldn't replicate the issue. However I see that F-Log has a messier red channel, so if you're unlucky, you could absolutely run into situations where the difference is as pronounced as in John Roque's examples. If there's an issue here, it must be about compression. That being said I wouldn't recommend against F-Log just yet, I never had any problems so far.

    It would be nice to see if an external recorder fixes the problem for those how are seeing it.

  10. 14 hours ago, John Roque said:

    I don't know if this has been addressed here but I'm finding some issues with flog with the xt3. Has anyone experienced these "pink splotches" before? These were shot in 10bit H.265. I'm finding that the HLG doesn't suffer from this issue. I placed a lut to emphasize the issue. Any help would be appreciated!

     

    flog2.thumb.jpg.881bbb69cf15e7a12ba39fc84dd5319a.jpg

    Any chance you could share the original for this clip? Just the F-Log one.

  11. 2 hours ago, Sage said:

    For the c++, there is a problem I'm trying to solve. Giant 4D arrays aren't supposed to be declared on the stack like this, but I haven't figured out how to conveniently pass them to functions any other way yet (vector pointer 'arrays' can only be 2D etc)

    Wish I could help with C++. I use Matlab for my stuff and it's pretty convenient. If I didn't have access to it I think I would use Python.

  12. 1 hour ago, Sage said:

    EC was made by filming a large number of color samples with both cameras, and then extracting coordinate data from those samples and supplying that data to a my own c++ program. As channel clipping occurs, the program attempts to straighten hue lines to follow that of the higher DR camera. There is a point at which those hue lines merge during clipping, such that clipped red is identical to yellow, for example. When these regions are detected,  they are reduced to near grayscale data:

    Oh yes, this is the kind of detail that excites me :)  Keep them coming. Too bad I can't scroll that still image ?
    I've chosen not to deal with hue shifts in my own conversions, but in your situation where one camera has way more DR than the other, it seems like something that can't be ignored.

  13. 48 minutes ago, KnightsFan said:

    Hmm, I looked in ffprobe, but I don't see that particular info. I suspect that the XT3 doesn't record ISO and aperture information for video files.

    It records a lot of stuff, including aperture and ISO, use Exiftool.

    Here's a sample output:

    ExifTool Version Number         : 11.29
    File Name                       : DSCF7556.MOV
    Directory                       : .
    File Size                       : 606 MB
    File Modification Date/Time     : 2019:01:26 19:27:17+01:00
    File Access Date/Time           : 2019:01:26 19:34:59+01:00
    File Creation Date/Time         : 2019:01:26 19:34:59+01:00
    File Permissions                : rw-rw-rw-
    File Type                       : MOV
    File Type Extension             : mov
    MIME Type                       : video/quicktime
    Major Brand                     : Apple QuickTime (.MOV/QT)
    Minor Version                   : 0.0.0
    Compatible Brands               : qt
    Movie Header Version            : 0
    Time Scale                      : 25000
    Duration                        : 25.00 s
    Preferred Rate                  : 1
    Preferred Volume                : 100.00%
    Preview Time                    : 0 s
    Preview Duration                : 0 s
    Poster Time                     : 0 s
    Selection Time                  : 0 s
    Selection Duration              : 0 s
    Current Time                    : 0 s
    Next Track ID                   : 4
    Track Header Version            : 0
    Track Create Date               : 2019:01:14 16:13:13
    Track Modify Date               : 2019:01:14 16:13:13
    Track ID                        : 1
    Track Duration                  : 25.00 s
    Track Layer                     : 0
    Track Volume                    : 0.00%
    Image Width                     : 4096
    Image Height                    : 2160
    Graphics Mode                   : srcCopy
    Op Color                        : 0 0 0
    Compressor ID                   : hvc1
    Source Image Width              : 4096
    Source Image Height             : 2160
    X Resolution                    : 72
    Y Resolution                    : 72
    Bit Depth                       : 24
    Color Representation            : nclc 1 6 6
    Video Frame Rate                : 25
    Time Code                       : 3
    Balance                         : 0
    Audio Format                    : lpcm
    Audio Channels                  : 3
    Audio Bits Per Sample           : 16
    Audio Sample Rate               : 1
    Matrix Structure                : 1 0 0 0 1 0 0 0 1
    Media Header Version            : 0
    Media Create Date               : 2019:01:14 16:13:13
    Media Modify Date               : 2019:01:14 16:13:13
    Media Time Scale                : 25000
    Media Duration                  : 25.00 s
    Handler Class                   : Media Handler
    Handler Type                    : Time Code
    Gen Media Version               : 0
    Gen Flags                       : 0 0 0
    Gen Graphics Mode               : ditherCopy
    Gen Op Color                    : 32768 32768 32768
    Gen Balance                     : 0
    Text Font                       : System
    Text Face                       : Plain
    Text Size                       : 12
    Text Color                      : 0 0 0
    Background Color                : 0 0 0
    Font Name                       :
    Other Format                    : tmcd
    Format                          : Digital Camera
    Information                     : FUJIFILM DIGITAL CAMERA X-T3
    Movie Stream Name               : FUJIFILM MOV STREAM 0130
    Make                            : FUJIFILM
    Camera Model Name               : X-T3
    Modify Date                     : 2019:01:14 16:12:24
    Artist                          :
    Thumbnail Offset                : 985974
    Thumbnail Length                : 8447
    Copyright                       :
    Exposure Time                   : 1/100
    F Number                        : 4.0
    ISO                             : 640
    Sensitivity Type                : Standard Output Sensitivity
    Date/Time Original              : 2019:01:14 16:12:24
    Create Date                     : 2019:01:14 16:12:24
    Shutter Speed Value             : 1/100
    Exposure Compensation           : 0
    Metering Mode                   : Multi-segment
    Version                         : 0130
    Internal Serial Number          : FF02B4624018     Y54774 2018:08:28 930330111016
    Quality                         : NORMAL
    Sharpness                       : 0 (normal)
    White Balance                   : Kelvin
    Saturation                      : 0 (normal)
    Noise Reduction                 : 0 (normal)
    Fuji Flash Mode                 : Not Attached
    Flash Exposure Comp             : 0
    Focus Mode                      : Unknown (65535)
    Slow Sync                       : Off
    Picture Mode                    : Manual
    Shadow Tone                     : 0 (normal)
    Highlight Tone                  : 0 (normal)
    Grain Effect                    : Off
    Auto Bracketing                 : Off
    Blur Warning                    : None
    Focus Warning                   : Good
    Exposure Warning                : Good
    Film Mode                       : F0/Standard (Provia)
    Min Focal Length                : 18
    Max Focal Length                : 55
    Max Aperture At Min Focal       : 2.8
    Max Aperture At Max Focal       : 4
    Rating                          : 0
    Frame Rate                      : 25
    Frame Width                     : 4096
    Frame Height                    : 2160
    Lens Info                       : 18-55mm f/2.8-4
    Movie Data Size                 : 634417152
    Movie Data Offset               : 1050112
    Aperture                        : 4.0
    Avg Bitrate                     : 203 Mbps
    Image Size                      : 4096x2160
    Megapixels                      : 8.8
    Rotation                        : 0
    Shutter Speed                   : 1/100
    Thumbnail Image                 : (Binary data 8447 bytes, use -b option to extract)
    Light Value                     : 8.0

  14. On 3/14/2019 at 2:18 PM, androidlad said:

    Interesting. In Premiere Pro, that LUT gives a perfect visual match.

    I finally figured out why I experienced problems with the LUT. An incorrect YCbCr->RGB conversion will result in values outside the 0-1 range. The LUT sees these values as 0 and 1 in Resolve, that's the reason for the inaccuracy. Premiere handles the LUT differently, there is no clamping there, and the results will be perfect, identical to using the DCTL version in Resolve. However it's possible the build a perfect LUT for Resolve as well, which will come in handy for non-Studio users. I actually built one, I plan to publish it alongside a video describing the problem in detail.

×
×
  • Create New...