Attila Bakos

Yes, that's correct. For what exactly do we need more accuracy? We know all about F-Log, all the info is there in the data sheet provided by Fujifilm.

Fuji log uses 95-1023, because of the gamma curve. That's still a wider range than video range (64-940).

This is a bit oversimplified, a lot of cameras use the full range in their video files. Fuji is one of them.

ProRes is always interpreted as video range, even if it's a full range recording. I'm not even sure ProRes has flags for setting the data levels at all. When you set it manually to full range it becomes flatter, that's normal.

Don't bother with converting, we need to see how Resolve handles the original files. Maybe someone else can help us out.

Right click the clips in the media pool, choose clip attributes, then select full at data levels.

Okay I won't be able to test it for a while, but if anyone has Resolve 16, here are the files that I used in my video: https://drive.google.com/drive/folders/1GmZM2IlBIjiVHLdSlpHGRhZpDEg69zVZ Just download both of them, set the Ninja V clip to full range (or set both of them to be safe), and check if the jacket has the same reds in Resolve.

Nice shots! Which profile is this? The sun looks a bit weird in some of them (at 2:10 for example). Is this due to grading?

I can only do it sometime tomorrow. It's easy to test though. Shoot a color chart or something with reds, export a frame from Resolve, and do another export with ffmpeg like this: ffmpeg -i input.mov -vframes 1 output.tif Then compare output.tif with the frame coming from Resolve. If they look identical, the issue is fixed.

If we are lucky they fixed this issue:

That's actually a good advice, I watched some of Juan Melaras videos on repeat

I didn't watch all of it, but he doesn't seem to convert S-Gamut to Rec.709. I know that he has skills and a good reputation, but I always find it amateurish when people apply some contrast and forget about the gamut.

One of the files he uploaded is actually H.264.

Just tested it with similar settings and conditions, my unit doesn't have this issue.

Yes I only need to use a single CST node after the fix and then the Arri LogC to Rec709 LUT. The problem is concatenating, because the matrix fix works in a different domain. That is, it does not require a shaper to work with values outside the 0-1 range. In theory I could use a shaper to bring values into the 0-1 range and alter the matrix fix to work with these new values (if I can), then I could concatenate the matrix fix, the cst node, and the arri lut. There is a problem though, while Resolve can load a 3D LUT with a shaper included (which is basicly an 1D LUT), Premiere doesn't seem to support this. So again, I think it's not worth the effort that's required.

You mentioned that it happens in various bitrates, but does it happen in both H.264 and H.265?

I couldn't create an all-in-one LUT that addresses the values outside of the 0-1 range as well. If I ignore those values then creating a HLG to Arri 709 LUT with the correction included is no problem. However, I can't include anything in a technical pack that's not technically perfect. In theory you could apply the correction matrix via DCTL and in that same DCTL you could load the HLG to Arri 709 LUT. (I never used it but I read somewhere that DCTLs can load LUTs.) This could work but only for Resolve Studio users, so I don't think it's worth doing.

The matrix fix has to go first (it's not an RGB color space correction, doesn't require linear space). You can absolutely concatenate LUTs, I can even make LUTs from CST corrections, but they will work in the 0-1 floating point range, just like the one you can download from Arri LUT generator. The matrix fix however is a special LUT, it's input range is wider. The reason for that is that a wrong YCbCr->RGB conversion will result in values outside of this range and you need to fix them as well. One does not simply concatenate LUTs with different input ranges But I guess I can scale everything else to the range of the matrix fix. Will be an interesting experiment as soon as I have time.

If RCM alters the RGB values before the first node, then you can't use these LUTs with them. I don't use RCM, but to use these LUTs I would recommend Davinci YRGB mode, then the correction LUT in the first node, and then a CST node to simulate what you do in RCM. There is only a minor difference in the header of the file, the data is exactly the same. What you say is theoretically possible if the math for HLG to Alexa 709 conversion is known.

I removed the free fix, and created a package with more options, including DCTLs: http://colorizer.net/index.php?op=technical On the bottom of the page you'll still find an option to fix these issues for free using FFMPEG. I can include more stuff in the package if any of you have suggestions.

Just keep in mind that you can't fix a bad yuv to rgb conversion with cst. So if you know the math, create a dctl that undoes the 709 matrix and applies the 601 matrix. You can also create one for hlg that undoes the 709 matrix and applies the 2020 matrix. I think I'll create a package with all the possible fixes for this issue, in lut and dctl format, and I might ask a few dollars for it.

Sometimes I feel stupid that I give away stuff like this for free..

I understand your issue but I honestly don't know what's causing it, OSX is unknown territory for me. What kind of matrix do you need?

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.