Davinci Color Managed Luminance mapping issue?

Anyone have any thoughts on this. I am getting a result that appears to be incorrect to me. It seems that the Davinci YRGB color management is not correctly applying the luminance mapping in certain circumstances

Resolve 15.2.4
Basic Project setup using these color management settings
Input space: Arri Log-C
Timeline space: Arri Log-C
Output space: Rec709 Gamma 2.4
Davinci YRGB Color Managed
Luminance mapping set to simple
Saturation mapping set to default

Graded as normal, monitor output looks as expected.
Rendered assets as both Quicktime Prores4444 and EXR (rec709G2.4)
The rendered clips in other applications look correct and match the picture seen on the resolve monitor

here is where we see the issue.
Bring the Rendered assets back into Resolve and drop them into a new track on the timeline to A/B between them and the graded RAW clip.
Rendered assets are tagged as REC709 Gamma 2.4 (as rendered)

The Luminance on the rendered asset now does not match the RAW graded clip.

I rebuilt this in another project that did not use Davinci Color Management (using color transform nodes to created the color space conversions on the raw assets)
And The clips match correctly.

It's my expectation that if an asset tagged the same as the output space is brought into the project and timeline that the color management as well as the mapping is essentially bypassed.
What appears to be happening is that the asset tagged in the same space as the defined output space is still getting luminance mapping while bypassing and color space conversion.

Can anyone verify this or explain why this is an expected result.
This is not an issue I have noticed previously.

Bring the Rendered assets back into Resolve

Did you change the Input Space for that clip? Or is it still being interpreted as Arri Log C?

Rendered assets are tagged as REC709 Gamma 2.4 (as rendered)

thanks Jim, but yes absolutely. Incoming assets were tagged as they were rendered in rec709 gamma 2.4
Also tried various other similar settings to no avail.

The test project removing color management proves the hypothesis that its down to Luminance mapping not being correctly bypassed when a matching color space tag is used on a clip

You timeline is set to LOG so in this case bypass won't behave same as Rec.709 2.4 tag. If your timeline would match your source (Rec.709 2.4) then you wouldn't see any changes.

You timeline is set to LOG so in this case bypass won't behave same as Rec.709 2.4 tag

Sorry maybe I was not clear.. I am not setting any clips to bypass.. As Bypass would by definition default to the defined project input space (which in this case is AWG/LogC)

If a clip is set to Rec.709 2.4 (tag)
The timeline is set to LogC (or whatever, linear, slog, etc)
The OUTPUT is set to Rec709 2.4
In this case if the clip listed above is on the timeline the color management should see that its the same colorspace and gamma as the output and pass it through with no processing, unless a correction is applied.
OR
it would do a colorspace conversion from regardless and do Rec709 2.4 --> AWG/LogC --> Rec709 2.4 and thus appear to pass the image untouched to output.
Thus the RENDERED clip would visually match the RAW graded clip on the same timeline.
This is not the case, as the color management appears to be passing the Rec709 2.4 to output untouched but still applying the Luminance mapping as if it was a LogC asset.
This results in a the Rec709 2.4 clip looking visibly darker and (result of luma mapping)

This exact clip in an unmanaged project matches the graded raw exactly

What you are seeing is essentially the equivalent of render transform in ACES. To bypass it you would need a compound input transform that is the inverse of both technical output transform and render transform.

If that is the case then this is exactly the problem.
the inability to bypass output tonemapping (an issue in ACES as well) is quite problematic in many cases.

In this case we are trying to verify the validity of a rendered output against its source.
If what we are saying is true this is essentially impossible as it would require the creation of a custom inverse tonemap.

I again go to the question, if an asset tagged in the EXACT same space as the output (ODT) in a color managed project is placed on a timeline why would the colorspace conversion be bypassed but not the tone and gamut mapping.
I would love someone at BM to explain the reasoning as maybe its just beyond me.

On the other topic of ACES....
ACES does this as well I agree by default, and it can be extremely problematic in instances where, for example a client provided sRGB asset (say screen content for a phone in a commercial) is being added to a timeline and needs to pass untouched through to output. ACES tonemapping maps white value of 1 to .82 based on its filmic tone curve.
This creates a problem where the incoming image and outgoing image are not identical.
In EVERY other application that uses ACES and OCIO we can obviously create custom IDT's and ODT's that remove this tonemapping. In Resolve as it does not support OCIO natively we cannot.

I get the reason and math behind output tonemapping. But shouldn't this be able to be bypassed when needed. (think white titles in an aces feature project..)

In basic ACES logic, there are no situations where IDT matches ODT because one is on the input end (camera, scanner) and other on the display end (monitor, projector). You can't capture footage with your monitor, so why would you need reverse IDT for that? But people do need these inversions, usually for the same reasons you already outlined, all kinds of display referred graphics etc, plus importing exported footage again, without applying RRT twice.

This is a question to BMD, why doesn't their implementation provide these inverse RRT+ODT transforms or means to construct these out of the box without plugins. Disabling RRT on clip by clip basis is probably architecturally very problematic because in ACES project, all blendings etc are done in working space before RRT and if you have two layers blended with one having RRT on and another off, you get a kind of chicken and egg problem.

Oh yeah I know, I have had this conversation with ACES peeps as well. As a concept in a LAB it makes sense, in practical application it does not. Hence why most major studios (and even small ones like mine) have hacked apart ACES to use what works toss out what does not.

Personally I would prefer ACES to provide ODT's with and without the filmic tonemap. Or at least create it in a way that makes it easier to isolate the gamma transform and the tonemap so they can be applied with and without each other as I have done in my pipeline.
But again Resolve does not support OCIO so we are stuck..

At any rate, back to the main subject. BM if you read this can PLEASE have some form of inverse tonemapping available so we can bypass this issue? Or at least publish it so we can create our own DCTL to do the inversion

I'm pretty sure Resolve uses standard ACES RRT so you can build an inversion DCTL right now. And inverse ODTs for each necessary input, which is also quite a lot of work and takes some digging in OCIO. Afaik ODT is not simple inverse of IDT with same name, because IDT moves data from source to ACES2065-1, but ODT moves data from OCES to output where OCES is the idealized display for which RRT does its mappings.

Thanks Hendrik,
I agree and yes I am fairly sure as well its standard RRT. That is basically what we have done in our studio pipeline and you are very correct we could create our own DCTL, but as we all know this kinda defeats the purpose of color management.
That being said I have done some playing with Paul Dore's ACES OFX setup and that is quite cool, But again its sort of a plugin based color management.
Just seems to me that a simple implementation of OCIO solves so much (which by the way can be used as a node in the fusion panel.. so hello.. its already in the applciation)