Luca Leocádio Soares

Rec.2020 P3D65 Limited

Recommended Posts

Good Day, Luca.

I´m looking for a solution to this issue as well.

Someone on the Black Magic Forum thinks it´s related in how Davinci Resolve handles the Data Levels.

I also discovered that the gamut in the monitor signal are limited but that the gammut in the the render exceeds the P3 limits, I'm having issues with the ODT P3-D65 St2084 (1000 nits) also, mostly in compressions.It appears that the gamut limits aren´t working in the render process and is specially tricky if the container is on Video Levels.

So far, the only way I´ve found  is use Gamma Limiter in the last nodes of the shots wich causes gamma issues. off the top of my head Make a test with limit gammut in the timeline´s node might be a good option.

Please let me know if you come across any idea.

 

Resolve_zGXZYXXubI.png

Link to comment
Share on other sites

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.

 image.thumb.png.d4fc3cd21135b4d4136a96e1d8874feb.png

Link to comment
Share on other sites

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

Link to comment
Share on other sites
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.  

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.