Interpretation issues of Fujifilm video files in Davinci Resolve, Premiere Pro and Final Cut Pro

[androidlad]

20 hours ago, Attila Bakos said:

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.

What's the difference between Resolve cube and Premiere cube? Just clamping?

Can you maybe put in colour space mapping LUTs with the matrix fixes combined? For example, HLG to Alexa 709 with matrix fix as one single LUT?

 

[Attila Bakos]

3 hours ago, thephoenix said:

how does it work with resolve color management ?

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.

 

49 minutes ago, androidlad said:

What's the difference between Resolve cube and Premiere cube? Just clamping?

Can you maybe put in colour space mapping LUTs with the matrix fixes combined? For example, HLG to Alexa 709 with matrix fix as one single LUT?

 

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.

[Llaasseerr]

On 5/3/2019 at 4:12 AM, Attila Bakos said:

What you say is theoretically possible if the math for HLG to Alexa 709 conversion is known.

You can break it down by doing HLG to Scene Linear under the HLG LUT menu -> custom matrix fix ->  Rec2100 (Rec2020) to AWG (CST node) -> Linear AWG to the Alexa 709 look (download a LUT from the Arri LUT generator).

I would do a sanity check to confirm it matches without the matrix fix, then add it in.

As for baking it down into a single LUT, I know I can do this in Nuke but that's an expensive piece of software so it may not be an option for everyone. 

Edit: corrected order of operations.

[Attila Bakos]

4 hours ago, Llaasseerr said:

You can break it down by doing HLG to Scene Linear under the HLG LUT menu -> custom matrix fix ->  Rec2100 (Rec2020) to AWG (CST node) -> Linear AWG to the Alexa 709 look (download a LUT from the Arri LUT generator).

I would do a sanity check to confirm it matches without the matrix fix, then add it in.

As for baking it down into a single LUT, I know I can do this in Nuke but that's an expensive piece of software so it may not be an option for everyone. 

Edit: corrected order of operations.

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.

[Attila Bakos]

9 hours ago, Attila Bakos said:

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.

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.

[Llaasseerr]

On 5/6/2019 at 10:01 AM, Attila Bakos said:

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.

Fair enough that the correction needs to go first and work on the camera original image. In which case there's no need to break up the CST operation with the HLG to linear in one node and linear to LogC in the next one. So if I'm understanding you correctly, could you just use a CST node after your matrix fix, followed by an Arri logC to Rec709 LUT then concatenate the whole thing? There is then no explicit intermediary stage there that has a floating point output outside 0-1 and your start and end points are normalized images.

Having said that, you should be able to handle values outside 0-1 with a shaper LUT so as to prevent clipping. I can definitely do this in Nuke. But then is Resolve really clipping something if you generate a LUT which first goes from HLG to linear then linear to LogC, then Rec709? I haven't tried in Resolve. But going to LogC is inherently a shaper LUT.

[Attila Bakos]

4 hours ago, Llaasseerr said:

Fair enough that the correction needs to go first and work on the camera original image. In which case there's no need to break up the CST operation with the HLG to linear in one node and linear to LogC in the next one. So if I'm understanding you correctly, could you just use a CST node after your matrix fix, followed by an Arri logC to Rec709 LUT then concatenate the whole thing? There is then no explicit intermediary stage there that has a floating point output outside 0-1 and your start and end points are normalized images.

Having said that, you should be able to handle values outside 0-1 with a shaper LUT so as to prevent clipping. I can definitely do this in Nuke. But then is Resolve really clipping something if you generate a LUT which first goes from HLG to linear then linear to LogC, then Rec709? I haven't tried in Resolve. But going to LogC is inherently a shaper LUT.

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.

[Llaasseerr]

On 5/7/2019 at 11:46 PM, Attila Bakos said:

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.

Gotcha, the old concatenation issue. I find that Nuke is a lot more transparent about stuff like this so I don't have to dig too deep. In fact I use Nuke as a sanity check and prototype for stuff I'm trying to do in Resolve.

I was reading the main X-T3 thread and I wanted to check in on this thread to say that I tested the original clips to see if the new Resolve 16 beta 3 fixed your original 601 vs 709 issue. On my machine (Macbook Pro with Vega 20 GPU) it does indeed now match the Reds in his jacket. However in 16 I now need to set the ProRes clip data levels to Video, not Full levels. This kind of makes sense considering the typical ProRes usage scenario. As long as the full dynamic range is coming in and the luma is as intended, I'm fine with that.

Separately, I'm still getting an issue on my machine at least, with clipped detail in the h.265 footage straight from camera. I think this is just a v16 beta issue but I'd be interested to know if anyone else is seeing this. I've reported it to BMD. 

Attached are screen grabs where I graded up to clearly show the issue. The waveforms (not attached) also show the clipping. My workaround for now has been to transcode the h.265 to ProRes 422HQ using EditReady, and then in Resolve set the ProRes to Video Levels to match the h.265 at Full levels - the luma levels then match, but it's not clipped. I believe the issue may be a bug with GPU decoding of h.265 clips.

 

[Llaasseerr]

I just tried turning off GPU decoding of HEVC files and the h.265 clip is now way too lifted and flat when set to Full levels. Clearly this is buggy. So doing it on the GPU yields the "correct" result, except for the clipping. Transcoding to ProRes 422HQ in EditReady seems to be the best workaround for me right now to get the full image displaying correctly in Resolve.

[Attila Bakos]

I just updated to Resolve 16 beta and the issue seems to be fixed. All Fujifilm files including HLG are interpreted with the correct matrix. The changelog mentions Fujifilm files but the fix seems to be general, it's seems that the matrix coefficients tag is now respected. The latest Premiere still has issues though.