Color managed workflows fail to apply forward/inverse OOTF

When performing color transforms between scene-referred and display-referred it is necessary to apply forward OOTF going from scene to screen referred and inverse OOTF when going back.

In an unmanaged workflow Resolve automatically correctly sets these options in the CSTs. However in a managed workflow Resolve fails to do so for the implicit CSTs performed by Resolve, and this causes colorspace-aware tools to apply improper adjustments when using a display-referred timeline colorspace with scene-referred clips because the failure to do the proper OOTF adjustments results in an incorrect implicit linear translation required and performed by these tools.

For example, this causes the HDR Global wheel to apply an incorrect calculation for the exposure adjustment.

When performing color transforms between scene-referred and display-referred it is necessary to apply forward OOTF going from scene to screen referred and inverse OOTF when going back.

I'm confused. Why are you going "between" scene-referred and display referred? Are you taking (let's say) a display-referred session and bringing it into a new scene-referred session? That's always been a disaster for me, and one of those things I recommend that my students never do just to avoid trainwrecks. What exactly are you dealing with?

I would rather just start the entire session over again, or find a way to just export a flattened file and then convert it from there into the new colorspace (assuming there are no potential gamut/clipping errors). Trust me, I've seen worse situations.

Not quite sure I entirely get what you mean, because I have seen it work as expected. You're going display (Rec709) to scene (DWG) to display (Rec709), am I right?

What you can do to really be sure the inverse OOTF for spaces like Rec709 or HLG etc is applied when going into the scene space is by using the IDTs with "(scene)" in the name. Those all contain the OOTF.

Not quite sure I entirely get what you mean, because I have seen it work as expected. You're going display (Rec709) to scene (DWG) to display (Rec709), am I right?

What you can do to really be sure the inverse OOTF for spaces like Rec709 or HLG etc is applied when going into the scene space is by using the IDTs with "(scene)" in the name. Those all contain the OOTF.

Thanks. Digging deeper I determined the issue occurs when the Timeline working luminance is set to the default of SDR 100, which occurs whenever Rec.709 is selected as the timeline working space. Switching to any scene-referred timeline working space changes the luminance to HDR 1000, which corrects the behavior. This mimics the difference of not applying a forward/inverse OOTF and since it only occurred when I selected a display-referred timeline working space I'm assumed it was because Resolve was failing to apply those, where now it's clear the issue is related to the Timeline working luminance setting.

Here's a short video demonstrating what I'm seeing: