Luca Leocádio Soares July 30, 2019 Share July 30, 2019 Hi everyone, I'm trying to find the best workflow to export a Rec.2020 ST2084 1000 nits master but limited to P3D65 color space. In Resolve I can even set this as an ODT, but when I watch the ProRes master, I can see its gamut is beyond the P3 triangle. Can anyone help with this? 1 Link to comment Share on other sites
Oscar Isaac Molina Villegas May 12, 2021 Share May 12, 2021 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. Link to comment Share on other sites
Luca Leocádio Soares May 12, 2021 Author Share May 12, 2021 Hi Oscar, To be honest I don't believe it''s related to data or video levels. At the time the solution was to apply a lut, which was limiting the gamut, inside Autodesk Flame. Link to comment Share on other sites
Oscar Isaac Molina Villegas May 12, 2021 Share May 12, 2021 Hi Luca. That LUT it´s part of the Autodesk Flame library? or did you created in another software?. Cheers. Link to comment Share on other sites
Luca Leocádio Soares May 12, 2021 Author Share May 12, 2021 No it's not. We've created it on lightspace. Link to comment Share on other sites
Oscar Isaac Molina Villegas May 12, 2021 Share May 12, 2021 is theare a chance that you can share it to me? Link to comment Share on other sites
Luca Leocádio Soares May 12, 2021 Author Share May 12, 2021 Sure! See if it works for you. REC2020_p3_limiter.cube 1 Link to comment Share on other sites
Oscar Isaac Molina Villegas May 12, 2021 Share May 12, 2021 Thank You Luca. Link to comment Share on other sites
Ben Price November 22, 2021 Share November 22, 2021 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! Link to comment Share on other sites
Luca Leocádio Soares November 22, 2021 Author Share November 22, 2021 After upgrading to Resolve 16, we haven't seen this issue anymore and you can download the LUT on the comment above. Link to comment Share on other sites
Ben Price November 22, 2021 Share November 22, 2021 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. Link to comment Share on other sites
Mazze November 23, 2021 Share November 23, 2021 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
Ben Price November 26, 2021 Share November 26, 2021 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
