Input DRT Issues

For posterity, I'm documenting issues with having Input DRT enabled by default ever since it was introduced in Resolve 17 with the "simplified" color management.

By having Input DRT enabled, Resolve will apply some form of tone scale mapping on the input source, therefore distorting what is fed into the timeline. To exemplify this, I've shown some sample waveform screenshots below with and without Input DRT enabled. These may be some extreme examples, but the propensity for Resolve to distort a clip due to Input DRT needs to be noted regardless.

Note: Output was set to Bypass & Output DRT disabled to show the exact problem.


Sample - HDR1000 Timeline No Input DRT

hdr1000_no-drt.jpg (162.61 KiB) Viewed 4897 times

Sample - HDR1000 Timeline With Input DRT

hdr1000_drt.jpg (161.53 KiB) Viewed 4897 times

And with HDR4000 NIT timeline this time...


Sample - HDR4000 Timeline No Input DRT

hdr4000_no-drt.jpg (161.94 KiB) Viewed 4647 times

Sample - HDR4000 Timeline With Input DRT

hdr4000_drt.jpg (163.4 KiB) Viewed 4647 times

When Input DRT is disabled, the footage fed into the timeline is the same, whether HDR1000 or HDR4000 NITs. Otherwise, what's fed into the timeline is distorted from the onset.

What's happening makes sense to me. The footage is being properly mapped to the desired range.

How complex would it be to explain why that's wrong?

Think of the Input DRT like a forced LUT that's applied on the first node and clips the highlights, alters the mid-tones by making gamma adjustments and effectively "bakes" the look in.

Now try making a 2 stop exposure reduction of the whole scene and watch those clipped highlights get pushed further down with no highlight recovery available.


As another example, say you have a clip for which you've bypassed the Input Transform and perform a Color Checker Match or even to use a "Color Space Transform" on the first node. The highlights are now "hard" limited for the source Gamma, effectively reducing the dynamic range, and the source gamma curve itself is completely distorted from what the footage was originally shot with. When that footage is then normalized using a plugin or CST, the hard clipping is easily visible and other aspects of the "transformed" gamma curve are warped as well - garbage in, garbage out.

Tone mapping shouldn't be force fed into the timeline by default as part of the input transform unless the user explicitly and knowingly wishes to do so. There is already tone mapping being applied on the output (unless the user disables that too).

Now try making a 2 stop exposure reduction of the whole scene and watch those clipped highlights get pushed further down with no highlight recovery available.

I wonder though is it clipped or is it mapped. I thought the input DRT was only mapping the luminance range to specified timeline working luminannce. Yes in that sense the original ratio between mids and highs is altered and can't be recovered upon stopping down.

I too believe that it's weird and unintuitive to include mapping in a scene conversion step but this goes hand in hand with the idea that a timeline luminance exist in the first place. Why? Can't the Output DRT just map whatever scene referred data you have to desired display space?
And why is the luminance being increased when the chosen timeline nits is higher than input? (HDR4000 example)

For this reason I don't really use this method of management.

I wonder though is it clipped or is it mapped. I thought the input DRT was only mapping the luminance range to specified timeline working luminannce. Yes in that sense the original ratio between mids and highs is altered and can't be recovered upon stopping down.

Yes it's mapped up or down, but in practical terms, when it's mapped down to the designated luminance peak, it's "clipped" in the sense that those highlights are no longer "recoverable", as you noted.

I too believe that it's weird and unintuitive to include mapping in a scene conversion step but this goes hand in hand with the idea that a timeline luminance exist in the first place. Why? Can't the Output DRT just map whatever scene referred data you have to desired display space?
And why is the luminance being increased when the chosen timeline nits is higher than input? (HDR4000 example)

Completely agree.

Think of the Input DRT like a forced LUT that's applied on the first node and clips the highlights

I don't see that happening, though.

Looking at a BRAW clip with specular highlights that exceed 1000 nits, I can get those back if I check the Highlight Recover option in the RAW Settings.

I thought the input DRT was only mapping the luminance range to specified timeline working luminannce.

That's what I'm seeing.

I was perusing the Reference Manual today and saw this.

"A key benefit of the color space conversions that RCM applies is that no image data is ever clipped during the Input to Timeline color space conversion. For example, even if your source is log-encoded or in a camera raw format, grading with a Rec. 709 Timeline Color Space does nothing to clip or otherwise limit the image data available to the RCM image processing pipeline. All image values greater than 1.0 or less than 0.0 are preserved and made available to the next stage of RCM processing, the Timeline to Output color space conversion."

What's written is not what's practically experienced. It may have been written before v17 simplified Color Management.

Try it out yourself. DRA Attached.

Simply Enable/Disable Input DRT in the project settings.

FYI,

HLG also has major issues when Input DRT is enabled... as I reported some time ago:

viewtopic.php?f=21&t=141131

Hi, I'm testing this using Resolve 18.6.4 and apparently everything sits where it should with DRT Input set to DaVinci, am I missing something or this has been already resolved?