Attila Bakos

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

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

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.

You're asking the guy who just so happens to have a gay porn actor as his profile picture I know, I know, how do I just so happen to know that... the URL of his picture is telling.