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

[Attila Bakos]

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.

 

[andrew_dotdot]

Thanks for the LUTs and ffmpeg fix technique.

[Attila Bakos]

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

[andrew_dotdot]

How does this work now with the color space transformations? As things stand now, I usually have four nodes where the first node is a rec 2020 to rec.709 color space transformation then a node with any exposure adjustments then another color space transformation back to rec 2020 from rec.709 and then finally the Eterna LUT from Fuji. Where would your correction LUT want to go?

[Attila Bakos]

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. 

[androidlad]

Great video. I submitted a ticket to Adobe to address this issue, maybe you could also submit a ticket with a link to this video?

Your English is great and your accent is hot.

[Attila Bakos]

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

[thephoenix]

@Attila Bakos in your video you say it only affects fuji internal files, so no issue with ninja v files recorded from xt3 ?

[Attila Bakos]

35 minutes ago, thephoenix said:

@Attila Bakos in your video you say it only affects fuji internal files, so no issue with ninja v files recorded from xt3 ?

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

[Papiskokuji]

2 hours ago, thephoenix said:

@Attila Bakos in your video you say it only affects fuji internal files, so no issue with ninja v files recorded from xt3 ?

I understood it was the opposite. The external files were the defective ones.

I know there's the same problem with Sony external recorded files. The luminance range isn't the same (I knew the fix, to go from video range to full range, or the other way around). And there's also a slight shift in color. I've developped my "looks" for h264 files from my Sony's. I just bought the Ninja V (despite Jeromy Young's crazy act  ) and I can't get the same skin tones with externally recorded prores files. They are more orangey and weird after applying a rec709 lut to the slog2 footage. I'd like to get the exact same starting point when I record externally. Anyone knows if I can use @Attila Bakos 's LUT ? Maybe you have a fix ? You seem to know much about these issues. Do you know if Sony's color difference between internal/external is the same interpretation problem from the NLE as with Fujis ?

Anyway, very interesting video. It's a shame not more people talk about this issue which is big to me (external recording with all these cameras having a shift in color and gamma).

[Attila Bakos]

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

[Papiskokuji]

13 minutes ago, Attila Bakos said:

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

Great ! I'll upload the videos this week-end ! Thank you so much !

[thephoenix]

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

[buggz]

@>attila-bakos

Thanks for the explaination and the LUT!

 

[Attila Bakos]

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.

[Llaasseerr]

Setting aside the 709 vs 601 issue, I've loaded the same Lazy Video Guy internal and external clips initially in Resolve 15 and I was able to get matching data levels when setting to full range. I then upgraded to Resolve 16 and now the h.265 clip comes in as video range when set to full. To get it to match the ProRes full range, I need to apply your "full to legal resolve" lut.

I then downgraded to Resolve 15 to double check that it matches. Now I have the same issue as in the 16 beta, which makes me think there's an underlying library that got updated by the beta and did not get rolled back when I reinstalled 15.

I'd be interested to hear if anyone else has had this issue.

[Llaasseerr]

I've done some HLG tests with the caveat that I seem to be seeing this "video levels" interpretation issue with full range h.265s now in Resolve 16 (see my post above). So right now, my test is inconclusive even after rolling back to Resolve 15 to do a sanity check. However as a workaround I'm using the "full to legal" lut for now.

What I did notice is that the metadata tags for the internally recorded HLG are:

Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant

For the externally recorded ProRes it's all BT.709 for those tags which is clearly incorrect. We weren't paying much attention to the Atomos setup so maybe there was a "HLG" switch on it that tells it to embed the correct metadata. 

I had also used Editready to convert F-log clips, and it fixed the problem I'm reporting about the incorrect video levels interpretation of h.265. Something interesting though is that if I convert the HLG h.265 to ProRes using EditReady, it preserves the metadata tags. It means the converted HLG doesn't match the Atomos recorded HLG. However I feel the recorded HLG is interpreted incorrectly by Resolve because of its incorrect metadata. So the EditReady converted HLG is probably correct, and it matches the h.265 once I add the "full to legal" lut to the h.265.

[Attila Bakos]

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.

[Llaasseerr]

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.

[Attila Bakos]

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.