Blackmagic Forum

The Behaviour of the Rec.709 timeline in RCM is... inconsistent... and especially varies based on Input and Output DRT combinations.

Given that Rec.709 is the default preset in RCM, this has an impact on the end result, though it may not be initially noticeable to the average user. But once you see it, you can't un-see it.

When Rec.709 Gamma 2.4 is selected for the timeline (as appears to be the default), there is in fact a gamma shift that is happening when only Output DRT is enabled or when both Input and Output DRT are enabled.

This is especially visible when only Output DRT is enabled and one changes the timeline setting from Gamma 2.4 to Scene. The Gamma shift becomes quite obvious.


Along similar lines, another issue is that some of the the Color Wheel and HDR Grade panels seem to behave based on a Rec.709 Scene gamma curve even though the timeline is set to a different Rec.709 Gamma and "Color Space aware grading tools" is selected. A prime example of this is the Exposure setting in the HDR panel.

Gamma shift when changing timeline gamma does sound like a bug if timeline setting is used as an intermediate space (changing working space shouldn’t imho change the appearance if no additional grade change is applied). What the compound effect with output DRT could be, hard to say, reasoning about RCM2 makes my head hurt.

Colorspace aware grading tools should do just that, give the same feel, whatever the timeline gamma is. What this feel should be is another story.

They're both bugs.

It's just that people don't notice due to the net effect DaVinci DRT has in compressing the final output.

It's a bit like two Ferraris... Only one is the real thing whilst the other one is a DIY replica made from used Toyota Camry parts. But they both look and feel almost the same from the outside when driven down a 20 zone with a glossy lick of paint (DaVinci DRT).

What does DRT stand for?

Jim Simon wrote:What does DRT stand for?

Davinci Resolve Timeline. And also Display Rendering Transform. Good luck searching the manual with same abbreviation used for both.

In this context it's Display Rendering Transform.

Think of it like the RRT from ACES

I don't think there are any bugs at play but to be honest I don't know why an Input DRT exists in the first place and what it does exactly.

To expect the exact same results from different Output DRTs is impossible because each individual one is designed differently. ACES/IPP2/K1S1/DaVinci etc. all have a different way of rendering this.
If I keep both in and out DRT on DaVinci nothing changes when flipping between Rec.709 2.4 and Scene.
Only if I disable the input DRT but disabling that removes some the tonemapping so changing the timeline colorspace to anything will always look different.

This is where your implied issue lies I guess. In an ACES workflow there is no such thing as Input DRT. Everything is internally technically converted to a single colorspace and only the output has a designed display rendering transform so no matter what colorspace you would work in the output would always be the same.

shebbe wrote:This is where your implied issue lies I guess. In an ACES workflow there is no such thing as Input DRT. Everything is internally technically converted to a single colorspace and only the output has a designed display rendering transform so no matter what colorspace you would work in the output would always be the same.

You are implying that in RCM2, everything is not converted to single timeline colorspace? If it isn’t it makes any reasoning about the RCM2 hopeless because everything becomes relative.

ACES can do Input DRT allright, if you choose one of the ODTs as IDT. This applies inverse ODT and inverse RRT. In Nuke I use this all the time to reverse stuff that has gone through ODT, usually to check that what I wrote out is correct.

I’m not sure what benefits Input DRT is supposed to serve in RCM2, how do you all understand the motivation behind it? To me it looks more like doubled forward tonemapping...

RikshaDriver wrote:Think of it like the RRT from ACES

Thanks Asim, but...we don't set an RRT in ACES, so I'm equally unfamiliar with that.

Jim Simon wrote:

RikshaDriver wrote:Think of it like the RRT from ACES

Thanks Asim, but...we don't set an RRT in ACES, so I'm equally unfamiliar with that.

Think of it as a ”pleasing look generator”, which applies certain characteristics to image data so that it looks ”better”. Technically RRT is the middle-man from scene-referred domain to idealized display domain abbreviated OCES (imaginary perfect display that displays images that look good to humans). ODT then moves data from ideal display to actual practical output space.

Yeah, that's what I got from some brief research. It's a bit of engineering I'm sure I could understand were I to start at the beginning. But as my work isn't that high end, I think I might take more of a "telephone" approach, leave my understanding at "how to use it" and bypass "how it works".

Thanks guys.

shebbe wrote:I don't think there are any bugs at play but to be honest I don't know why an Input DRT exists in the first place and what it does exactly.

To expect the exact same results from different Output DRTs is impossible because each individual one is designed differently. ACES/IPP2/K1S1/DaVinci etc. all have a different way of rendering this.
If I keep both in and out DRT on DaVinci nothing changes when flipping between Rec.709 2.4 and Scene.
Only if I disable the input DRT but disabling that removes some the tonemapping so changing the timeline colorspace to anything will always look different.

I'm talking purely about SDR 100 NIT limited timeline settings here, not something else. There are clearly issues with the way Tone mapping is being done.

Just a few examples below... where the input source is set to S-Log2 and the output to Rec709 Gamma 2.4:

Timeline Gamma 2.4 with both Input and Output DRT


Timeline Gamma 2.4 with only Output DRT or No DRT


Timeline Scene Gamma with Output DRT

And also:

Scene Gamma Timeline with no DRT

Both reported issues are still present in 17.2.1