![]() ![]() You might say that this doesn't matter to you, but the difference is there. Open the files in different tabs and switch between them. But I also used zscale to do the scaling manually and the results are identical to what FFMPEG does by default: 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. (Resolve has the same colors, I checked it.) This is from a HLG video using the BT.709 matrix, extracted with FFMPEG. I believe you're talking about transfer characteristics, which is basicly the linearization function.ĭisrespecting the matrix coefficients tag will result in different colors, as you have seen in my video. Respecting or disrespecting the matrix coefficients tag won't result in blown-out footage. Premiere ignores the tags and decodes everything in BT.709, so HLG files have that flat look ready for grading. If we change the decoding parameter to BT.709 SDR, the images return to the flat look as seen on camera. This is why in Scratch, X-T3 HLG files are default blown-out (on an SDR display) because Scratch respects the tags. We use HLG as an alternative log profile.īT.2020 matrix coefficients tag is required for HDR playback, or on-the-fly conversion for SDR playback. I've had some promising early results too, but I'm working out a few kinks. ![]() 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'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. 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 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. 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.Īs 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. So right now, I need to add the compensatory LUT as a workaround to force the internal clip to full range. 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. ![]() Alexa Log-C ProRes carry all BT.709 tags as well, ARRI has to put additional metadata field to say it's Log C. HLG/BT.2020 tags are required for instant HDR playback on end user devices, or for automatic HDR to SDR conversion. There's no need to use a LUT for that.Īlso it's not really a problem for external ProRes for HLG to contain all BT.709 tags. In Resolve, data/video level is arbitrary really, it's easily selectable in "Levels" clip setting. 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. However I feel the recorded HLG is interpreted incorrectly by Resolve because of its incorrect metadata. It means the converted HLG doesn't match the Atomos recorded HLG. Something interesting though is that if I convert the HLG h.265 to ProRes using EditReady, it preserves the metadata tags. 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. 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. Matrix coefficients : BT.2020 non-constantįor the externally recorded ProRes it's all BT.709 for those tags which is clearly incorrect. What I did notice is that the metadata tags for the internally recorded HLG are: However as a workaround I'm using the "full to legal" lut for now. So right now, my test is inconclusive even after rolling back to Resolve 15 to do a sanity check. 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). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |