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