Resolve Output DRT Bugs

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

RikshaDriver

  • Posts: 641
  • Joined: Sun Aug 12, 2018 10:08 am
  • Location: Melbourne
  • Real Name: Asim Siddiqui

Resolve Output DRT Bugs

PostTue May 17, 2022 5:25 am

I'd like to preface this with a note that there are issues with both Input and Output DRT.

I've documented Input DRT issues before here: viewtopic.php?f=21&t=156192

Now, for Output DRT, there are a number of issues I've observed particularly with SDR settings...


Example 1:

Input Color Space: Any
Timeline Color Space: Rec.709 Gamma 2.2 or 2.4 or 2.6
Timeline Luminance SDR 100
Output Color Space: Rec.709 (Scene)
Input DRT: None
Output DRT: DaVinci

Result: Output of Rec.709 (Scene) resembles Rec.709 Gamma 2.4 instead - BUG

If Timeline Luminance is changed to something else, things get even more wacky even though the source is SDR and Input DRT is none - BUG



Example 2:

Input Color Space: Any
Timeline Color Space: Rec.709 (Scene)
Output Color Space: Rec.709 Gamma 2.4
Input DRT: None
Output DRT: DaVinci

Result: Output of Rec.709 Gamma 2.4 resembles Rec.709 (Scene) instead - BUG

If Timeline Luminance is changed to something else, things get even more wacky even though the source is SDR and Input DRT is none - BUG


Example 3:

Input Color Space: Any
Timeline Color Space: Rec.709 (Scene)
Output Color Space: Rec.709 Gamma 2.2 or sRGB
Input DRT: None
Output DRT: DaVinci

Result: Midtones/shadows of Rec.709 Gamma 2.2 & sRGB are crushed even more than Rec.709 (Scene) - BUG

If Timeline Luminance is changed to something else, things get even more wacky even though the source is SDR and Input DRT is none - BUG


In all cases, disabling Output DRT fixes everything.


Sample DRA attached if anyone wishes to test it out for themselves:

Output DRT Bugs.dra.zip
(33.07 KiB) Downloaded 28 times



For reference, the expected Middle Gray values are shown in the table at the bottom of the page:
https://xtremestuff.net/where-in-the-wo ... ddle-gray/
GitHub Projects: https://github.com/xtremestuff/
Commercial Plugins: https://xtremestuff.net/store/
Offline

Peter Chamberlain

Blackmagic Design

  • Posts: 13875
  • Joined: Wed Aug 22, 2012 7:08 am

Re: Resolve Output DRT Bugs

PostTue May 17, 2022 6:12 am

is this on v18.0 b2?
DaVinci Resolve Product Manager
Offline

RikshaDriver

  • Posts: 641
  • Joined: Sun Aug 12, 2018 10:08 am
  • Location: Melbourne
  • Real Name: Asim Siddiqui

Re: Resolve Output DRT Bugs

PostTue May 17, 2022 6:20 am

It's on v17

The issues have been there since RCMv2 was introduced
GitHub Projects: https://github.com/xtremestuff/
Commercial Plugins: https://xtremestuff.net/store/
Offline

RikshaDriver

  • Posts: 641
  • Joined: Sun Aug 12, 2018 10:08 am
  • Location: Melbourne
  • Real Name: Asim Siddiqui

Re: Resolve Output DRT Bugs

PostFri May 20, 2022 5:04 am

I can confirm this is also present on 18b3 and earlier
GitHub Projects: https://github.com/xtremestuff/
Commercial Plugins: https://xtremestuff.net/store/
Offline

Peter Chamberlain

Blackmagic Design

  • Posts: 13875
  • Joined: Wed Aug 22, 2012 7:08 am

Re: Resolve Output DRT Bugs

PostFri May 20, 2022 7:05 am

Reviewed internally with color scientists here and they report this is not a bug, it's working as designed.

The issue is that when a DRT is applied it handles the required OOTF conversions between scene and display referred spaces. If the DRT is only applied on output and not input then the user will need to grade to compensate for the input OOTF if the input and timeline spaces are referred differently (ie. one is scene the other display referred).

Th user will also need to grade the nominal input max luminance of the input space to the timeline space’s max. luminance, if they are different levels (ie. 709 input and HDR timeline).

The presets do not have this issue as they use DRTs for both input and output. This is the recommended practice or not using DRTs at all.

Alternatively the user can use ‘Custom’ mode and then it is up to them to manage the relevant changes in referral.

The work-around, if the user really wants to work that way, is to use add a CST transform at the start of their grade and set the input and output spaces to match the timeline, then they can toggle the OOTF (forward, backward or off) and see which OOTF matches the expected look (it will depend on how the input and timeline spaces are referred).
DaVinci Resolve Product Manager
Offline

RikshaDriver

  • Posts: 641
  • Joined: Sun Aug 12, 2018 10:08 am
  • Location: Melbourne
  • Real Name: Asim Siddiqui

Re: Resolve Output DRT Bugs

PostFri May 20, 2022 2:11 pm

The issue is that when a DRT is applied it handles the required OOTF conversions between scene and display referred spaces. If the DRT is only applied on output and not input then the user will need to grade to compensate for the input OOTF if the input and timeline spaces are referred differently (ie. one is scene the other display referred).


Thanks for the clarification Peter. That was the missing piece of information. It's not JUST tone/gamut mapping then.

It seems a bit counterintuitive to be honest. If someone is using a color managed pipeline and outputting to a Scene Referred preset, there would be good reason for doing so. The "Artistic OOTF" would already have likely been considered as part of this.

Similarly if someone is outputting to a Display referred preset, there is likely reason for doing so. Again, the "Artistic OOTF" would already have likely been considered as part of this as well. Bringing that display referred output back to scene referred with an OOTF doesn't make sense with modern systems and proper color management.

Maybe I'm opening up a philosophical Pandora's box here... 8-)

It would be great to at least allow the OOTF to be toggled (permanently?) under the Project Settings.

The issue is that when a DRT is applied it handles the required OOTF conversions between scene and display referred spaces. If the DRT is only applied on output and not input then the user will need to grade to compensate for the input OOTF if the input and timeline spaces are referred differently (ie. one is scene the other display referred).

Th user will also need to grade the nominal input max luminance of the input space to the timeline space’s max. luminance, if they are different levels (ie. 709 input and HDR timeline).

The presets do not have this issue as they use DRTs for both input and output. This is the recommended practice or not using DRTs at all.


But what you're saying regarding Input & Output DRT only holds true if the SDR pipeline is wholly Scene referred or Display referred. The default RCMv2 SDR preset is Rec.709 Gamma 2.4 and is display referred from Timeline to Output.

As soon as the user changes the Input or Output to Rec.709 (Scene) or something else Scene Referred, the Inverse OOTF or OOTF is applied respectively - even with Input and Output DRT. If the user has other Scene referred inputs such as S-Log 2 for example, no OOTF seems to be applied because Resolve for whatever reason doesn't appear to consider S-Log, V-Log etc as Scene referred. But if you now change the output of this same project to Rec.709 (scene) with both Input and Output DRT enabled, you get hit with the OOTF, which now makes it exactly the same as Rec.709 Gamma 2.4!

It's all a bit of a mess.


Also, does the OOTF use an assumed Gamma 1.2 or does it use BT.1886 or is it based off the actual function of the respective display referred Gammas? The reason I ask is that when the Timeline is set to Gamma 2.6, 2.2 or 2.4 and the Output setting to Rec.709 (Scene), it appears BT.1886 (or its simplified derivative) is always assumed for the Inverse OOTF.
GitHub Projects: https://github.com/xtremestuff/
Commercial Plugins: https://xtremestuff.net/store/
Online

4EvrYng

  • Posts: 596
  • Joined: Sat Feb 19, 2022 12:45 am
  • Real Name: Alexander Dali

Re: Resolve Output DRT Bugs

PostFri May 05, 2023 10:10 pm

RikshaDriver wrote:As soon as the user changes the Input or Output to Rec.709 (Scene) or something else Scene Referred, the Inverse OOTF or OOTF is applied respectively - even with Input and Output DRT. If the user has other Scene referred inputs such as S-Log 2 for example, no OOTF seems to be applied because Resolve for whatever reason doesn't appear to consider S-Log, V-Log etc as Scene referred. But if you now change the output of this same project to Rec.709 (scene) with both Input and Output DRT enabled, you get hit with the OOTF, which now makes it exactly the same as Rec.709 Gamma 2.4!

Does this still happen in DR 18.*?

Return to DaVinci Resolve

Who is online

Users browsing this forum: akyhne, Colbyc, lordwotton, panos_mts, peeceful, twonprod and 149 guests