Llaasseerr

I've tried this out in Resolve 16b3 with the same files and unlike Resolve 15, I need to set the ProRes clip to Video levels, not Full levels. Besides that, the colours now apparently match with the latest bug fixes. However I'm getting a separate luma clipping issue. Details over here in the original thread.

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.

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.

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.

Yes. That was my understanding. For sure it would be good to get a readily available fix out there for those that don't want to delve into the maths.

I also use Linux for work but I haven't gotten Resolve up and running on it yet. I was just thinking it would be handy to just work out the matrix whenever one is needed and then be able to apply it losslessly and mathematically with a Matrix node in Resolve. It's mind boggling that one is not included. I've implemented a static matrix transform as a dctl (Arri film matrix, just for fun) and that was easy, so in theory I could quickly do that for 601 to 709. However I think I'm going to try and focus on HLG now, so I can probably use the CST to solve any colour space issues. I'm still talking to BMD about the data levels issue.

I posted this topic on the BMD forum too: https://forum.blackmagicdesign.com/viewtopic.php?f=32&t=89799&p=503331#p503331

Re-reading what you're saying though, does this possibly account for the main issue I'm seeing with the video/full data levels not behaving predictably? That's the thing that's biting me the most, more so than colour shifts due to an incorrect matrix although that's important.

I hope you're on to something, which is why I thought of posting in this topic. But I'm not sure where this additional transform is happening under the hood. I haven't updated my Mojave install since updating (then downgrading) Resolve, so I don't see how any OS -level libraries could do this. I've escalated this to BMD support as well, so I'll see what they say. I did install OpenImageIO via Homebrew, which installed ffmpeg, not sure if that could have changed something that Resolve also looks at. I should describe my end usage scenario too. I'm planning for a SDR finish and I'm wanting to use HLG as a substitute log curve instead of F-log since it seems a better choice right now until maybe Fuji create an F-log2. I'm transforming it to a more familiar Arri LogC/AWG workflow once it's in Resolve. Thanks to @androidlad for his work with HLG that brought it to my attention! So basically if the HLG is living as a very flat log image on a 500 nit SDR display the same way a typical log captured image appears, then that is totally appropriate. I'm actually hoping that in a working install of Resolve 15, that this is all still behaving correctly. Also can anyone recommend a 3x3 matrix DCTL or OFX plugin so I can directly apply a matrix in Resolve like I can in Nuke?? I used to have one made by Paul Dore (baldavenger) but I kind of lost track of where that is on his GitHub.

It's exactly as I say it is. You could take the same clip and set data levels to video for one of them and full for the other and that is the exact visual result. However what I'm actually doing is setting both internal and external clips to full, but the internal clip has the appearance of the external clip if it was set to video. This is only since Resolve 16 beta. Edit. That's for F-log. For HLG, I would need to add the compensatory LUT twice, not just once, to get the internal clip to match the external.

I assume you mean Clip Attributes->Data Levels, which is what I'm using. The issue is that all of a sudden full levels on an internal clip is the same as video levels on an external clip (for F-log). This seems to be a bug introduced in Resolve 16 beta. So right now, I need to add the compensatory LUT as a workaround to force the internal clip to full range. I do realise the LUT is not necessary if everything worked properly, and that it's a very simple math function that could be written as a DCTL, or done in Nuke with a Grade node. As for the Atomos HLG issue, yeah I originally thought the same as you're saying that it wouldn't matter if all the tags are Rec709 so I'm glad you said that. And you're right actually. I just took another look at it and the issue is that if I set both the internal and external clips to full range, then I need to add the extra LUT twice to get the internal clip to match the full range luma levels of the ProRes clip. Obviously that's broken. So I don't know which one is correct. Possibly neither of them. I think this would have been easy to sort out in Resolve 15 prior to upgrading to 16, but now I've downgraded I'm seeing the same weird behaviour in 15 as well. I'll admit I come from film where I'm mainly dealing with EXRs and DPXs and I never have to think about these kinds of issues. And I have not needed to look closely at broadcast HDR yet, but I love the fact you're getting a great result with HLG as a substitute log curve for X-T3 capture. I've had some promising early results too, but I'm working out a few kinks.

Thanks, that's great to know. Right now I installed ffmpeg through homebrew and it didn't configure with --enable-libzimg. I'd be surprised if Atomos did not have some way of handling HLG more elegantly than what we did where we ended up with Rec709 tags. But we were shooting with an older 7" Ninja Flame I think, not the latest Ninja V. It did support HLG though. I think the important thing for me is to know what my baseline correct colour handling is in HLG. I'm assuming that if the full range issue on the internal files is sorted out then that is my baseline.

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'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.

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.

Is anyone else seeing an issue in the Resolve 16 beta where internal h.265 clips from the X-T3 interpreted as full range are actually now coming in video range compared to externally recorded ProRes clips? ie. the only way to get them to match now is to set the ProRes clip to video range and the h.265 to full range. In Resolve 15, I found I could set clip data levels to full range for both internal and external recordings and the luma levels matched - ie. they were full range.