Ben Price

On 11/23/2021 at 1:25 PM, Mazze said:

Depending on how much "bleeds" outside of the P3 gamut, it could simply be RGB vs. YUV.

Inside Resolve (or any DI system for that matter, with very few exceptions) all is RGB-based and so is your measurement.
When you then render out to a YUV based codec, the encoder used will convert the RGB data to YUV.
That conversion might introduce certain "spikes" that reach outside of the defined gamut.
Vice versa, when pulling the rendered result back in, the first thing that happens right after the decode, is a YUV to RGB conversion.
Effectively you now have two conversions in between your two measurements.

You can check against by exporting the original timeline as RGB DPX and pull those back in and analyse.
If they are a 100% match (as you're not going to YUV and back again with those) - the culprit lies with the YUV conversion,
and can't be avoided.

 

Cheers,
Mazze

Thanks Mazze, appreciate your response, we think that's something to do with it. The colour seems to be exceeding the P3 D65 gamut in the shadows, so desaturating them tends to do most of the leg-work bringing them with the legal limits.  

Thanks Luca, appreciate it. We're a little stumped as are BlackMagic, when using the Rec2020 P3D65 limited output transform we're seeing the colour exceed the confines of P3. Interestingly it doesn't occur when working on the project, only when bringing the export back in to look at the scopes.

We're currently having this same issue, did you ever work out a more permanent solution? Would it be possible to have the LUT too please? 

Thank you!