Mixed Color Spaces: Invert ODTs or not?

[Stefan]

Hey @allklier,

Thanks for taking the time to explore this thing.
Here are a few friendly clarifications.

Thus this ODT that was used to generate the Rec709 image isn’t a pure primaries/gamma transfer as one might have expected. And that is specific to the ACES environment and it’s math.

If you open Rec709 100nit dim image in your OS with native preview tools (like preview on mac, image viewer on rocky linux …) it looks the way it should.
Your conversion doesn’t. You converted not for video display, but using the simple gamma/gamut way, which is only meant to be an intermediate working state.
If you receive footage in “Video 709” it will be like the Ampas version.
If you open any scene-referred conversion from the AMPAS folder in nuke or flame and tag them correctly, and use ACES 1.0 color policy in flame, or the studio ACES1.3 OCIO1.2 config in nuke, all results will look like the AMPAS ‘video’ REF ( Rec709 100nit dim)

The inverted display transform does not seem to be working properly, or not as you expect. By all accounts it appears to be doing a double transform.

The ‘apparent double conversion’ you’re getting in your Flame setup is because you’re trying to convert a logC4 to … LogC4, but tagging the input as video. Just keep the view transform as it is by default, don’t invert it. The rest of the weirdness is because the action is set to video709, but you kept the text node in ACEScg, so it’s basically tagging the video from action as ACEScg in the following comp node . Then you have an input transform to convert from ACEScg to ACEScg … so yeah, things are not set properly. I can guaranty that the view transform works exactly as intended, even in invert mode.

This is the money shot, because it shows that you can stay all Rec709 or all ACEScg and comp images without dramatically distorting things. No need for inverted ODTs.

It shows that when you comp scene-referred with scene-referred it’s all good. This is not using any conversion from display referred to scene referred.

The only differences may be some specularity loss

Which is a big no go! option 1 would be bounced back because of all the clamping/ highlights losses.

Which gets me back to - Flame color management in the age of ACES is unnecessarily complicated and misleading.

That’s very subjective, and I strongly disagree

I’ll DM you and we can do a screen sharing session.

[Stefan]

@allklier, DM sent

[allklier]

Thanks for the great conversation and screen share. More follow-up investigation to do. Interesting topic.

[Stefan]

Yeah interesting discussion, thanks for your time, and nice to meet you.
I’ll look more into the .ctl files as soon as I can.

1 thing I’ve forgotten to mention from the beginning is that applying a clamp on a video source before using an inverted ODT eliminates some of the issues coming with inverted ODTs.

Another way is to invert the ACES 1.1 SDR-video (Rec.709 limited) instead of the default ACES 1.0 SDR-video (thanks @AdamF for finding that out!)

Edit:
Note: Clamping the source before further transforms compared to inverting the alternative ODT (ACES 1.1, rec709 limited) seems to lead to the same results, with a difference matte node’s gain to 10,000, so i’d assume that’s the only difference (clamp before)

[Stefan]

Interestingly, there’s indeed an inverted ODT .ctl in the AMPAS repo.
InvODT.Academy.Rec709_D60sim_100nits_dim.ctl

there are inverted ODTs for all these:

[doug-walker]

@Stefan, hey my friend, sorry for the delayed reply.

I don’t know of a perfect solution to the problem you posed. There are basically the two approaches that you are already using, each with their own pros/cons. I thought Randy’s post above summarized the situation perfectly.

And you raised a good point about clamping before inverting – if there are any colors outside the display gamut, this will prevent them from blowing up.

The inverse ODTs you reference are already present in Flame as the inverse View Transforms. There is no new magic there. That said, the ACES project has been working on a completely new family of ODTs and these will invert somewhat more cleanly (e.g. colors near the edge of the display gamut will invert) but development is still in progress.

Doug

[Stefan]

Hi @doug-walker! Thanks for chiming in my friend!

What do you think about the idea of a matchbox that would take an ACEScg render meant to be seen under a gamma-corrected (Untonemapped) display transform, and make it ‘look right’ when comping under ACES 1.0-SDR video?
Something that would do most of the work with appropriate math, and give the user some control to try to slip away from inverted ODTs common issues?
Meaning, this, as opposed to the down/up color transforms (down via input xform, and up inverting an ODT), which would still show the potential issues on 1 side, or the MasterGrade solution to get as close as possible to the visual desired result (and also avoiding common issues with the tonemap inversion) on the other side?
So again, as much as possible would be done using proper luminance and saturation compensations, and the rest left to the user?

[doug-walker]

I don’t understand what your proposed Matchbox would do that can not already be done with a View Transform.

One thing you could try is to use a highlight roll-off tool that is invertible (PhotoMap is a simple one) to undo some of what the inverse ODT does to your sRGB image. Then selectively apply the inverse (which may be tweaked to match as much of the look as possible) before re-applying the forward ODT.

There is no ideal solution I’m aware of, so that probably means the best solution will vary based on the specific inverse ODT artifacts you are running into in a given situation.

[johnt]

@allklier

I would welcome anyone double checking this to make sure I didn’t make any mistakes. I did go over it a few times, but anything is possible.

PS: I disabled the blur nodes, as it’s easier to compare, but I understand why you wanted them.

Hola

Where can I find
A_0001C024_220824_064331_p12SQ
and
Rec709_fromACEScg_ManualCST