Problem with Color managed workflow

Hi everyone,
I would like to understand the following operation:
- Color Science is set to Davinci Color Managed
- Custom Settings with Davinci WG/Davinci Intermediate set as timeline Color Space and Gamma
- When applying a CST transforming the timeline CS and Gamma to Davinci WG/Davinci Intermediate the image gets BRIGHTER. Why? The timeline CS and gamma already is set to Davinci WG/Intermediate.

Why is there a change altogether? I assumed it would have to remain unchanged as the original and target color space and gamma are identical. Are they not? What is my mistake here?

Thank you in advance!

Why are you applying the CST?

I need to know what the correct timeline CS and Gamma is. I want to apply a LUT that needs to be applied to Rec709 color space. Therefore I need three nodes. I first have to transform the timeline to Rec709, then apply the LUT and then transform it back to the timeline CS. I assumed it would have to deliver the same results when choosing timeline CS and Gamma as original in the first node and target in the final node, as when choosing Davinci WG/DAvinci Intermediate. But it doesn't. Why?

Untick "Apply Inverse OOTF", it messes up the conversion.

If BMD cares to explain what OOTF means when input and output are exactly the same, and why it isn't a no-op, would be nice.

CST enables OOTF when set to use timeline, even though using scene color spaces as the timeline color space.

when you manually set it to Intermediate -> Intermediate, it's disabled by default. They could easily fix this tbh.

BTW, side info on the OOTF:

There's only a handful of OOTFs in Resolve. Those are specified by the ITU Recs. Resolve in most cases applies the 709 OOTF except for PQ and HLG color spaces.

Untick "Apply Inverse OOTF", it messes up the conversion.

If BMD cares to explain what OOTF means when input and output are exactly the same, and why it isn't a no-op, would be nice.

I think OOTF only applies for rec709 Gammas and SRGB gammas
Here my Speculations :
Rec709 OOTF = Gamma Rec709(Scene) ➧ Gamma rec709
SRGB OOTF : Gamma SRGB ➧ Gamma 2.2

When you play with theses gammas in CST ... the OOTF checkbox checks by itself

IF someone can correct me I'll be very happy

I think OOTF only applies for rec709 Gammas and SRGB gammas

So why does it get enabled automatically in OPs case if it only applied to these? Adding rec709 or sRGB related OOTF in DWG/DI > DWG/DI conversion is nonsensical. It is nonsensical even if one of these were rec709 or sRGB, as the transform itself is already expressing EOTF or OETF or their combination.

OOTF expresses the end-to-end gamma from captured light to emit light on physical display. What has physical display got to do with random colorspace transform?

I think OOTF only applies for rec709 Gammas and SRGB gammas

So why does it get enabled automatically in OPs case if it only applied to these?

I have not the answer

Adding rec709 or sRGB related OOTF in DWG/DI > DWG/DI conversion is nonsensical. It is nonsensical even if one of these were rec709 or sRGB, as the transform itself is already expressing EOTF or OETF or their combination.

OOTF expresses the end-to-end gamma from captured light to emit light on physical display. What has physical display got to do with random colorspace transform?

I agree with you

It does not make a lot of sense in many cases. It should be really easy for BMD to change the default behaviour to something more reasonable. When "use timeline" is a scene space, it should respect that.

It is nonsensical even if one of these were rec709 or sRGB, as the transform itself is already expressing EOTF or OETF or their combination.

When Rec.709 is chosen as gamma it disables it (because it's included), when Gamma 2.4 is picked it isn't since it's not necissarily tied to the specification. But yea it needs to be fixed when timeline is set to something other than a display standard.

When Rec.709 is chosen as gamma it disables it (because it's included), when Gamma 2.4 is picked it isn't since it's not necissarily tied to the specification.

So the logic is "something rec709-ish was chosen, why don't we assume that user actually wants encoding for rec709 display and do an implicit fix...". A bandaid on long-established wrong assumption that rec709 calibrated display needs data encoding with gamma 2.4 I guess... Tries to fix one thing breaks ten others.

I wonder if Peter Chamberlain is ever going to comment on ANY thread that relates to all the color problems in a supposed color correction software... I accepted that ACES is a black hole long time ago, but come on, this is RCM.

I think the main 'problem' is that the CST or RCM allow separate primaries and gamma. You may argue that it makes it flexible but I can't think of any non-standard combination that you'd need. The color space list is also mixed up with color models which IMO should not be there but have their own OFX/DCTL for when you want to convert within your pipeline.

It's not hard you know...

2023-09-29 11_35_55-1403 - Truelight Colour Spaces 1 - YouTube.png (143.37 KiB) Viewed 5104 times

I think the main 'problem' is that the CST or RCM allow separate primaries and gamma. You may argue that it makes it flexible but I can't think of any non-standard combination that you'd need.

Why would separating gamut and transfer function introduce the need for OOTF?

Non-standard combinations are not super common but there are multiple cases where it can happen. One simple example: compositor receives AlexaWG/V3LogC footage but for "reasons" has to return as an exr sequence, with linearized data. In this case the returned sequence is a fairly non-standard combination of linear AWG. Same thing can happen with all kinds of different gamuts, and also when source gamut is initially unknown but work has to start (not uncommon when project is messy). In this case usual way is to apply a guesstimate transform for linearization, producing result which has unknown origin but known intermediate transform. If origin is later discovered, knowing the transform applied allows proper retransform but needs custom gamut/gamma setup to describe the content.

example: compositor receives AlexaWG/V3LogC footage but for "reasons" has to return as an exr sequence, with linearized data. In this case the returned sequence is a fairly non-standard combination of linear AWG.

I personally consider linear variants of camera and working spaces pretty standard for exactly what you describe there.

Yea, although adding linearized variants of every gamut bloats the list, so imho it still makes more sense to be able to select them separate. The caveat obviously is that it probably only works for technical transforms, as it isn't possible to deduce from the combination when to apply or inverse the tonemapping. For example in ACES, selecting gamut and gamma separately wouldn't allow differentiating simple CST-s and ODT-s.

And now thinking about it, above might actually be the reason for that OOTF forward-inverse mumbo-jumbo with hardcoded logic of when it tries to enable itself in CST.

Yes it would get bloated at some point. This is luckily already improved with categorization in the case of Input Color Space tagging in RCM. Filmlight solves it by hiding less common color spaces behind a key modifier. You can even customize what's shown yourself I believe. On top of that if you need custom spaces you can make/add them which we can't with RCM. I find that it makes more sense than what we currently have in Resolve.

Rec.709 isn't the only gamma. We can define Rec.2100 ST2048, DCI all as transfer functions. What's even more weird to me is that when DCI is chosen as gamma, forward OOTF is checked if it was unchecked previously. In my mind this should then behave the same as Rec.709 where it's included. On top of that, Gamma 2.6 without forward OOTF is not the same as DCI gamma.

I'm not experienced at all with cinema deliveries but I think there are unintended differences there.

I also don't understand the difference in gamma option: Rec.2100 ST2048 and ST2048 1000nit. That's the same thing no? Same mess as Rec.709 vs Gamma 2.4 I guess but picking these both keep their forward OOTF enabled.

I think the main 'problem' is that the CST or RCM allow separate primaries and gamma. You may argue that it makes it flexible but I can't think of any non-standard combination that you'd need.

Yes, and keep a "linear" check box ... like in the Fusion's viewer LUT editor

The color space list is also mixed up with color models which IMO should not be there but have their own OFX/DCTL for when you want to convert within your pipeline.

100% Agree : Yes let's separate Color Model from ColorSpace (Gamut & Gamma)

As a reminder NCLC have 3 distincts numbers to describe
- the Gamut = primaries + White Point
- the Gamma
- the Matrix to convert the Color model to RGB

It raises a semantic issue about the word ColorSpace. For some it's
- ColorModel +Gamut +Gamma (in RCM settings)
- ColorModel + Gamut (in CST)
- Gamut + Gamma (Monitors menu/settings)

I like the latter one : ColorSpace shouldn't include the ColorModel. It makes it more understandable.
Thanks

It raises a semantic issue about the word ColorSpace. For some it's
- ColorModel +Gamut +Gamma (in RCM settings)
- ColorModel + Gamut (in CST)
- Gamut + Gamma (Monitors menu/settings)

I like the latter one : ColorSpace shouldn't include the ColorModel. It makes it more understandable.
Thanks

I kind of agree, as color model is usually implied to be additive RGB, as components in other color models aren't (and sometimes can't) be represented by xy coords. I'm not good enough in linear algebra to immediately tell whether lets say Y'CbCr relates to XYZ base in a way that it can be expressed using a gamut matrix and transfer function, but my hunch is that it can. But the components themselves, Y, Cb and Cr can't be described directly using xy primaries I believe (sound contradictory, but as I said, I'm no algebra expert )

The reason for a seperate forward / inverse OOTF button in the CST OFX might also be due to legacy of the tool itself.

Up until Resolve 16, the CST OFX only had 3 tonemapping modes. None, Simple and Luminance. Luminance mapping was the only one customizable, but if you converted let's say Arri Wide Gamut LogC to Rec709 Gamma 2.4 you would always get an image that was to bright, especially in the lower mids / shadows (basically the OOTF was missing here). The only useable option was the Simple method. This one was close to to what the official K1S1 Arri LUT did, however not customizable at all, and it basically only worked good for Arri footage.

With Resolve 17 they introduced other tonemapping methods (DaVinci and Saturation mapping) and rebuilt the entire color management system. Instead of rebuilding each and every transform they just added one more block of code that got rid of the above problem of the missing OOTF along with adjusting the code of the Simple method. That's why (in my opinion) those buttons even exist, even if they don't always make a lot of sense.


Btw. if you open an old project from Resolve 16 or earlier times that used the CST OFX you will still find the old version, that now has a '(legacy)' in the name.

Instructive, thanks