Attila Bakos

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.

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.) 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: 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.

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

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.

Yes you have to be careful with externally recorded files. Unless you have some kind of switch they will have BT.709 flags, at least the ones I've seen so far, but sometimes the underlying data requires BT.601 or BT.2020 matrix, so the NLE will have no chance to show it correctly.

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.

What happens if you don't convert to ProRes? I'm asking because the changelog of 13.0.2 says that it now reads PQ/HLG color information accurately from ProRes containers.

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

@Papiskokuji If you can upload an internal and an external version of the same shot somewhere, I can take a look at it.

I can only speak of ProRes, but it was fine, no color issues there.

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:

But....ahhh... at least we have workarounds.

It looks great, but how you can protect the back of the screen when folded? Or the edge.

Is there a changelog somewhere?

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.

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.

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

I'll do that tomorrow. I already submitted one to Blackmagic. If you can, please do the same.

This correction should be the very first thing in the chain. Funny thing is that sometimes you will prefer the uncorrected version, especially with nature stuff, the wrong matrix gives a bit more warmth to the image.

I forgot to mention this in the video but the fixes should only be applied to non-HLG footage.

The issue this video covers was already mentioned in several topics, but I promised a video explanation and fixes, so here it is. Beware: long, boring, bad English.

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.

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.

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

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.