Final Explanation of Gamma and Color Shift Problems

Andrew, totally get what you’re saying. For people who don’t know how to set their equipment, an automated system may be the best option. But in reality manually setting everything is the only way to really see everything correctly, every time. But the automated system at the moment is deeply flawed, as made obvious by this long thread with differing results. But trying to compensate for a “dumb” user, will make the “smart” user see something wrong. I want the “smart” user to be rewarded for their effort. The “dumb” one probably won’t care or notice anyway.

I'm going to test YouTube very soon and will let you know. But I'm pretty confident that it will give me the same output as Vimeo with 1-1-1 tags. FYI, The source files are encoding as Rec709 (Scene) (Output color space) with 1-1-1 tags.

The OOTF is a kind of default way to convert the OETF into the EOTF. But my workflow would be a creative OOTF, because I'm not using standard LUTS / RCM math and converting LOG footage through various node structures. So the OOTF is custom. After I'm done with my file, I don't want any software to apply anything to it. There's no need. At 2.2 it is lighter, but in lighter environment, it looks perceptually the same as 2.4 in a dim surround environment, which looks exactly like what I saw. So they match, perceptually.

I would imagine that your results will be identical in Youtube. Again... Encoding REC 709 SCENE = 709 with no OOTF or = Rec709 Gamma 2.4 with Forward OOTF...

If you set RCM or CST to REC 709 scene.. the math is still being applied. The creative part of the OOTF + OUTPUT ENCODE will be identical if using 709 SCENE or Gamma 2.4 with forward OOTF (RCM using DRT) . However if you turn off the output DRT... The Gamma 2.4 with not have the Forward OOFT applied. AFIAK the only way to avoid tone mapping and get the OOTF applied is to use CST management, but I always use some tone mapping (usually luminance).

madchiller, yes those are all true. But why I would want to re-apply the forward OOTF with 1-2-1 tags is beyond me? 1-1-1 renders out a perfect match to the original grade. So if you didn't have the forward OOTF for some reason, you could tag 1-2-1 and then you would get a match, no? But my workflow is not done with CSTs or RCM, it's completely custom / manual, involving multiple DCTLs that are designed for the look I'm going for. Then once I'm happy with the grade, I tag 1-1-1 because it looks the same. The tags are defining the source and my footage is a rec709 (scene) source, it always is, once I applied a rec709 transform from Log. The 2.4 tag is simply wrong and is defining something that isn't correct.

To put it another way, let's say the tags were stating the output destination. In this case, Rec709 2.4 gamma. Let's say that the programmers all got together and sorted out all of the tagging issues (labels, software interpretation, etc.) and they said that a file encoded for the destination display of Rec709 2.4 was labelled "1-2-1". So any program / app that displayed this 1-2-1 tag would have the correct math for a Rec709 2.4 display. Let's say all the above is absolute and true across the board ok, in our hypothetical perfect world. Now, there are two users. User 1 has a windows PC with generic cheap LCD. User 2 has a new M3 MacBook Pro. How, would either of these users be seeing the same thing, with NCLC tags? There's just no way. That's not even getting into the thought that there are at least dozens if not hundreds of possible users and display outputs. What display space / gamma is the tag referencing? Don't you see the tremendous assumptions going on here? It just won't work, unless everybody was using the same display, software and code.

Even if we limited it to just Apple users, I can assure you that my testing these tags out on various laptops and iPhones / iPads (from 2013 laptops to 2015 iPhones, to 2023 desktop, etc.), no apple device really interprets the tags / look the same. But 1-2-1 tags always add another forward OOTF and look darker as a result. Which never looks right on ANY of the color managed devices / software I've EVER viewed it on. So the very thought that these tags will help anybody is really a pipe dream. Not to mention the idea that was mentioned about compensating for Dim surround vs bright and the gamma shift becomes a feature, not a detriment. Or that the 1-1-1 tag is literally the first tag and labelled according to the most used standard on the planet atm. It's just common sense really. So if doing SDR, color grade with a Decklink / ultra studio into a rec709 2.4 monitor and output to 1-1-1. There you go, you're done. No other way makes sense atm.

madchiller, yes those are all true. But why I would want to re-apply the forward OOTF with 1-2-1 tags is beyond me? 1-1-1 renders out a perfect match to the original grade. So if you didn't have the forward OOTF for some reason, you could tag 1-2-1 and then you would get a match, no? But my workflow is not done with CSTs or RCM, it's completely custom / manual, involving multiple DCTLs that are designed for the look I'm going for. Then once I'm happy with the grade, I tag 1-1-1 because it looks the same. The tags are defining the source and my footage is a rec709 (scene) source, it always is, once I applied a rec709 transform from Log. The 2.4 tag is simply wrong and is defining something that isn't correct.

To put it another way, let's say the tags were stating the output destination. In this case, Rec709 2.4 gamma. Let's say that the programmers all got together and sorted out all of the tagging issues (labels, software interpretation, etc.) and they said that a file encoded for the destination display of Rec709 2.4 was labelled "1-2-1". So any program / app that displayed this 1-2-1 tag would have the correct math for a Rec709 2.4 display. Let's say all the above is absolute and true across the board ok, in our hypothetical perfect world. Now, there are two users. User 1 has a windows PC with generic cheap LCD. User 2 has a new M3 MacBook Pro. How, would either of these users be seeing the same thing, with NCLC tags? There's just no way. That's not even getting into the thought that there are at least dozens if not hundreds of possible users and display outputs. What display space / gamma is the tag referencing? Don't you see the tremendous assumptions going on here? It just won't work, unless everybody was using the same display, software and code.

Even if we limited it to just Apple users, I can assure you that my testing these tags out on various laptops and iPhones / iPads (from 2013 laptops to 2015 iPhones, to 2023 desktop, etc.), no apple device really interprets the tags / look the same. But 1-2-1 tags always add another forward OOTF and look darker as a result. Which never looks right on ANY of the color managed devices / software I've EVER viewed it on. So the very thought that these tags will help anybody is really a pipe dream. Not to mention the idea that was mentioned about compensating for Dim surround vs bright and the gamma shift becomes a feature, not a detriment. Or that the 1-1-1 tag is literally the first tag and labelled according to the most used standard on the planet atm. It's just common sense really. So if doing SDR, color grade with a Decklink / ultra studio into a rec709 2.4 monitor and output to 1-1-1. There you go, you're done. No other way makes sense atm.

OK.. TAGS are simply Metadata... They only affect how a CM system might try to interpret the encoded file.

When you tag as 1-1-1... your not specifying anything past 709/709/709.... The middle "1" tag does not IMPLY a specific gamma value, and this can vary depending on the CM system....

1-2-1 specifies the gamma as UNDEFINED/UNKNOWN... There is however a specific "GAMA" tag that is set to 2.4 .. But Apple Quick Sync does not read it. We need an NCLC tag specific to Gamma 2.4.. just like how we have for HDR content or Gamma 2.2 (BT470m aka 1-4-1)

If you are not using RCM or CST you are not color managing the encoded file.
and I feel you are missing my point... When encoding Gamma 2.4 - Resolve isn't REAPPLYING the OOTF.. I am speaking regarding Pure math... Take an ARRI Log C file in, use a CST to transform, and OUTPUT REC 709 Gamma 2.4, or Rec709 SCENE. There is Math managing the encoded values... 709 SCENE = Gamma 2.4 with forward OOTF on ENCODE. Normally when transferring from a scene space to a display space you would apply a Forward OOTF, and an inverse OOTF, when transferring from a display space to a scene space.

However I was under the impression you were encoding SCENE (709 Gamma) via RCM.... but that is not the case as per this response, and therefore does not really matter now.

You are not encoding SCENE in pure sense either if you not managing. Your working SCENE REFERRED, grading by hand, and that is fine.. but don't think you are encoding REC709 SCENE just because you have selected SCENE for your tagging in a YRGB project. If not using RCM.... YRGB Project settings only dictate TAGS, not encoded values. You are simply encoding a scene referred grade, and Metadata Tagging 709/709/709.......

When you tag as 1-1-1... your not specifying anything past 709/709/709.... The middle "1" tag does not IMPLY a specific gamma value, and this can vary depending on the CM system....

1-2-1 specifies the gamma as UNDEFINED/UNKNOWN... There is however a specific "GAMA" tag that is set to 2.4 .. But Apple Quick Sync does not read it. We need an NCLC tag specific to Gamma 2.4.. just like how we have for HDR content or Gamma 2.2 (BT470m aka 1-4-1)

If you are not using RCM or CST you are not color managing the encoded file.

and you are missing my point... When encoding Gamma 2.4 - Resolve isn't REAPPLYING the OOTF.. I am speaking from Pure math... Take an Arri Log C file in and use a CST to transform and OUTPUT REC 709 Gamma 2.4 or Rec709 SCENE. There is Math managing the encoded values... SCENE = Gamma 2.4 with forward OOTF on ENCODE. However I was under the impression you were encoding SCENE (709 Gamma) via RCM.... but that is not the case as per this response, and therefore does not matter now.

You are not encoding SCENE in pure sense either if you not managing. Your working SCENE REFERRED, grading by hand, and that is fine.. but don't think you are encoding REC709 SCENE just because you have selected SCENE for your tagging in a YRGB project. If not using RCM.... YRGB Project settings only dictate TAGS, not encoded values. You are simply encoding a scene referred grade, and Metadata Tagging 709/709/709.......

I understand that tags are metadata, yes. The encoded file is exactly the same underneath, of course.

The middle "1" tag isn't adding a specific gamma within the tagging system (assuming you're referring to how the "2" undefined tag is working), but the "1" represents the rec709 1.96 gamma. So it is assuming that.

But this keeps going back to whether or not the encoded file should be tagging itself or tagging the end monitoring standard. Also SDR and HDR work off of slightly different principles (can't speak about BT470m). The Rec2100 spec specifies an EOTF, OOTF, OETF system, which is different from the Rec709 spec which is just the OETF. So that adds to the confusion here. If we are tagging the rendered file as with an "intended display standard of", then tagging Rec709 2.4 gamma (1-2-1, with gamma 2.4 tag) would make sense, but if we are tagging the rendered file as "this is a rec709 encoded file" then the 1-1-1 rec709 tagged file makes sense. But it does seem like HDR avoids some of these pitfalls by having a complete system within the 2100 spec.

I am color managing the encoded file, I'm just doing it manually. RCM and CST are using pure math to transform one space / gamma into another. But there are infinite number of ways you can get to a pleasing image all the same (as in my case with manual creative intent). When encoding I agree that Resolve isn't reapplying the OOTF. I was talking about how the tags are managing my rec709 encoded file. The 1-2-1 tag is darkening, by adding some sort of additional TF. If QuickTime is not reading, I don't really care. Because, in the end, 1-1-1 reads correctly what I send out of Resolve.

I'm working under a custom transform to Rec709. So, yes, the grade is happening in a scene referred state. But that would be the case with a CST or RCM. your grade is happening underneath, unless you're grading after the transform, which would be more uncommon these days.

Let me use another example. If I shot with a camera that was filming in a rec709 profile (not log). I then took that file and dropped it in a timeline within Resolve. The timeline was using Davinci YRGB, no color management. I then rendered out that timeline with 1-1-1 tags. The file that was encoded in the camera and the rendered timeline clip with 1-1-1 tags would look identical on a rec709 2.4 monitor. If I instead took that same timeline and rendered out with 1-2-1 tags, it would look darker than the original camera encoded file. The above example is the same as when I take a log file and transform it (in any way possible) and render it out with 1-1-1 tags. They both are "encoded" to be viewed on a rec709 monitor, in the way I intended.

I think you are looking to NCLC color management to "reinterpret" the clip so that the monitor "appears" to match the intended space / gamma. I'm saying that color management still assumes some sort of universal space / gamma or else, otherwise what is the reference for the transforms? Isn't that assumption still needing the screen to be calibrated to some standard, so that it can switch to all relative calibrations? So it kind of defeats the purpose of screen management. I mean, I understand that relative management would make certain things appear closer to the intended result, but it wouldn't be an absolute match, to what was seen in the grading suite.

Obviously, this system is seriously flawed. The fact that we can't easily say to each other how it works or doesn't work is evidence of that. Don't you agree? If the system was clearly labelled with no ambiguity about what the tags defined, then it might start us down the right road and get us closer to all seeing the intended result. In the end bypassing NCLC tags and labelling my file with the correct monitoring spec will allow the broadcaster / streamer to know my intent and broadcast correctly. NCLCs aren't smart enough for their own good.

System is simple:

For historical reasons, color scientists defined many permutations of broadcast video color spaces. As a result, you should tag your media files with color information that describes the video media. If you don’t, the untagged media content might not match your intentions across all the different configurations and environments your customers encounter.

It says quite clearly what whole system is about. You should tag file as per its actual nature so color sync can have a good start to perform required conversions. Plain simple.

1-1-1 means for color sync about 1.96 gamma.
1-2-1 itself means no gamma, but this tag should always come with gamma tag specified where you put actual value eg. 2.4. OSX does read this information. This flagging is only QuickTime specific, not VUI, so not universal.

NCLC tags are replacement for simple gamma tag.
NCLC is about meaningless as it’s pure Apple thing. VUI headers are important as they are used in many different devices.

I am color managing the encoded file, I'm just doing it manually. RCM and CST are using pure math to transform one space / gamma into another. But there are infinite number of ways you can get to a pleasing image all the same (as in my case with manual creative intent). When encoding I agree that Resolve isn't reapplying the OOTF. I was talking about how the tags are managing my rec709 encoded file. The 1-2-1 tag is darkening, by adding some sort of additional TF. If QuickTime is not reading, I don't really care. Because, in the end, 1-1-1 reads correctly what I send out of Resolve.

I'm working under a custom transform to Rec709. So, yes, the grade is happening in a scene referred state. But that would be the case with a CST or RCM. your grade is happening underneath, unless you're grading after the transform, which would be more uncommon these days.

Let me use another example. If I shot with a camera that was filming in a rec709 profile (not log). I then took that file and dropped it in a timeline within Resolve. The timeline was using Davinci YRGB, no color management. I then rendered out that timeline with 1-1-1 tags. The file that was encoded in the camera and the rendered timeline clip with 1-1-1 tags would look identical on a rec709 2.4 monitor. If I instead took that same timeline and rendered out with 1-2-1 tags, it would look darker than the original camera encoded file. The above example is the same as when I take a log file and transform it (in any way possible) and render it out with 1-1-1 tags. They both are "encoded" to be viewed on a rec709 monitor, in the way I intended.

I think you are looking to NCLC color management to "reinterpret" the clip so that the monitor "appears" to match the intended space / gamma. I'm saying that color management still assumes some sort of universal space / gamma or else, otherwise what is the reference for the transforms? Isn't that assumption still needing the screen to be calibrated to some standard, so that it can switch to all relative calibrations? So it kind of defeats the purpose of screen management. I mean, I understand that relative management would make certain things appear closer to the intended result, but it wouldn't be an absolute match, to what was seen in the grading suite.

With 1-2-1 you are seeing a darkened result due to a mismatch in the APPLE Color management. If you viewed this file on windows with a 2.4 calibrated display.. you would not see it as darkened, and it will match the 1-1-1 version. Furthermore if you simply bring the 1-1-1 and 1-2-1 files back onto the timeline in resolve.. they will be identical.

We are targeting Display spaces and Gammas, and yes, Color management should read the tagging and transform, based on those CS/Gamma tags, to the actual Display space/Gamma as per the ICC data set for the display.. not some crazy interpretation that Apple thinks it should be.

If 2.4 graded file still has encoding gamma of about 1.96 then it will be darker as you tell Apple gamma is 2.4.
Change tag to 1.96 and it will look the same as 1-1-1. In this case 1-1-1 tag is fine. Use reference BT.1886 mode in new Apple display which will put 1.22 gamma correction to get preview as of 2.4 gamma, which should match ref screen set to 2.4 and TVs set to BT.1886.

When delivering material for VFX, compositing, grading, tracking, DCP production, etc. (Flame, Maya, Nuke, Baselight, etc.), I always export the material with Rec.709 (scene) output to have a HD Profile 1-1- 1 and I am writing to everyone that DaVinci has a bug and the material is not gamma 1.96, but gamma 2.4.

I've lost hope that Blackmagic will ever fix the bug. It is more important to them how the material is displayed on YouTube or in QuickTime on Mac and I ignore the professional environment.

Well, I don't know what encoding gamma should be (no one seems to know for sure). It's not 1:1 system, so encoding gamma may be around 1.96, but viewing 2.4. This is why you still get 1.96 encoding, but with reference mode you get different curve which in Apple system is implemented as 1.22 boost setting (1.96*1.22= around 2.4). This actually may be correct thing and what ref screens and TVs with BT.1886 do.
If you want pure 2.4 encoding/decoding then you have to do it as a custom setting.

If you want pure 2.4 encoding/decoding then you have to do it as a custom setting.

I don't know how set DaVinci output for gamma 2.4 that profile after export will be HD 1-1-1.
I don't think it's possible.

It's not possible probably because it's not a standard
Standard is viewing at 2.4 gamma (or more precise around 2.4 defined by BT.1886 ), not encoding at 2.4.

It's not possible probably because it's not a standard
Standard is viewing at 2.4 gamma (or more precise around 2.4 defined by BT.1886 ), not encoding at 2.4.

What's is your output settings if delivery is to broadcast, please?

It's gamma 2.4 but it doesn't mean this is encoding gamma.
I also thought it's, but looks like it's not necessarily the case as whole idea is that you don't get 1:1 system.
Viewing gamma is different than encoding.
As far as I understand 2.4 gamma in Resolve is correct choice for broadcast delivery, so don't try to create something 'own' You just need you ref screen to be set to BT.1886 (or 2.4 gamma).

I assume BT.1886 has not defined encoding part but viewing part, so this affects end point devices like monitors, TVs etc. It's there where new math should be present.
On new Apple devices it's present in form of new reference BT.1886 mode, which should be used together with standard 1-1-1 tagged file. This should give correct final preview as on ref screen. This apparently match latest Resolve viewer as well.
In this case 1-2-1 tag is wrong and a lot what I said in the past is not needed (some if it wrong). Solution is BT.1886 ref mode (with its original 1.22 boost setting).

It's gamma 2.4 but it doesn't mean this is encoding gamma.
I also thought it's, but looks like it's not necessarily the case as whole idea is that you don't get 1:1 system.
Viewing gamma is different than encoding.
As far as I understand 2.4 gamma in Resolve is correct choice for broadcast delivery, so don't try to create something 'own' You just need you ref screen to be set to BT.1886 (or 2.4 gamma).

Thank you for answer. The problem is that when I choose gamma 2.4 for the output, Transfer Chareacteristics is missing in the metadata, which causes problems and it certainly shouldn't be that way.

DaVinci is also the only program (of the ones I know - Flame, Baselight, Assimilate Scratch, Final Cut Pro 7/X, Adobe Premiere) that does it like this.

I assume BT.1886 has not defined encoding part but viewing part, so this affects end point devices like monitors, TVs etc. It's there where new math should be present.
On new Apple devices it's present in form of new reference BT.1886 mode, which should be used together with standard 1-1-1 tagged file. This should give correct final preview as on ref screen. This apparently match latest Resolve viewer as well.
In this case 1-2-1 tag is wrong and a lot what I said in the past is not needed (some if it wrong). Solution is BT.1886 ref mode (with its original 1.22 boost setting).

This certainly makes sense, but the problem is that exporting from DaVinci is not the last step. I give exports to other people for compositing, tracking, grading, etc. Many other people and a lot of software are involved in the production of the work. Some externs work in programs I don't even know

This won't matter. If they monitor on ref screens set correctly all will be fine. It's the end device which is the key point here.

It's gamma 2.4 but it doesn't mean this is encoding gamma.
I also thought it's, but looks like it's not necessarily the case as whole idea is that you don't get 1:1 system.
Viewing gamma is different than encoding.
As far as I understand 2.4 gamma in Resolve is correct choice for broadcast delivery, so don't try to create something 'own' You just need you ref screen to be set to BT.1886 (or 2.4 gamma).

Thank you for answer. The problem is that when I choose gamma 2.4 for the output, Transfer Chareacteristics is missing in the metadata, which causes problems and it certainly shouldn't be that way.

DaVinci is also the only program (of the ones I know - Flame, Baselight, Assimilate Scratch, Final Cut Pro 7/X, Adobe Premiere) that does it like this.

Just set gamma tag in advanced export panel to Rec.709-A. This will do 1-1-1 tag.

Just set gamma tag in advanced export panel to Rec.709-A. This will do 1-1-1 tag.

I don't want to use it. It brings chaos. Better export to Scene or I'll think about what you say about exporting without Transcode Characteristics parameter. Thanks!

In this multilayered chaos, order of fixes and their importance is:

1. Make sure actual data storage (encoding) is proper
2. Make sure data is tagged appropriately
3. Make sure that tag is correctly interpreted in software X
4. Make sure that interpretation produces correct transform for output display
5. Make sure that data actually reaches display correctly (signal path)
5. Make sure output display itself is accurate

Usual "simple" solution slapped on gamma shift is either "buy io boxy" and "calerbite the disabply" which as seen above is of least importance and does not fix anything unless all the previous steps are correct.

Just set gamma tag in advanced export panel to Rec.709-A. This will do 1-1-1 tag.

I don't want to use it. It brings chaos. Better export to Scene or I'll think about what you say about exporting without Transcode Characteristics parameter. Thanks!

What chaos? You want files encoded with correct gamma and tagged as 1-1-1. No chaos.
You may use Rec.709 scene as well- end result is same as 2.4 gamma setting, but tag is 1-1-1 by default.

Perhaps it is time to rename this topic as "Ongoing Explanation of Gamma and Color Shift Problems".

With all this AI stuff going on in Resolve surely it's time there was simply a button labeled "fix Gamma" that took care of *everything* so we didn't have to worry about this stuff ourselves

Except that there is usually nothing wrong with the gamma of data in the file to begin with.

Perhaps it is time to rename this topic as "Ongoing Explanation of Gamma and Color Shift Problems".

Far from final for sure

Well, it was started as explanation of the problem, not as problem solution

With all this AI stuff going on in Resolve surely it's time there was simply a button labeled "fix Gamma" that took care of *everything* so we didn't have to worry about this stuff ourselves

wouldn't that be amazing

In this multilayered chaos, order of fixes and their importance is:

1. Make sure actual data storage (encoding) is proper
2. Make sure data is tagged appropriately
3. Make sure that tag is correctly interpreted in software X
4. Make sure that interpretation produces correct transform for output display
5. Make sure that data actually reaches display correctly (signal path)
5. Make sure output display itself is accurate

Usual "simple" solution slapped on gamma shift is either "buy io boxy" and "calerbite the disabply" which as seen above is of least importance and does not fix anything unless all the previous steps are correct.

This is very correct. It is somehow understated how important a Blackmagic brand IO device, in combination with a calibrated (not factory calibrated) monitor is. If you have these, your colormanagment is properly set, and you tag your export color and gamma as 709 to get 1-1-1 profile tags, you can feel good knowing you are seeing and delivering an accurate image. If it looks different after exporting, it could be for a bunch of different reasons. Just know it seriously won't look right on any non calibrated mismanaged display. That's the sad truth. If you don't believe me, Find a studio mastered film, and compare it on multiple displays. They won't match either.

You may think, "what's the point of using a calibrated monitor with an IO device then?" It's because each display drifts in its own direction over time or is just plain incorrect. using an IO with calibrated display ensures it won't be drastically different on other displays.

Second that. While you can't be sure what others see, you can be sure that your own output sits right in the middle.
Imagine you have an uncalibrated display and don't know it's far off to one side, let's assume purple.
Now somebody is watching your grade on a display that is off to the opposite, in this case green. He/she will complain that your video is far too green, since you tried to counteract a purple tint without knowing it, already grading it to green without even noticing.

When encoding Gamma 2.4 - Resolve isn't REAPPLYING the OOTF.. I am speaking regarding Pure math... Take an ARRI Log C file in, use a CST to transform, and OUTPUT REC 709 Gamma 2.4, or Rec709 SCENE. There is Math managing the encoded values... 709 SCENE = Gamma 2.4 with forward OOTF on ENCODE. Normally when transferring from a scene space to a display space you would apply a Forward OOTF, and an inverse OOTF, when transferring from a display space to a scene space.

I feel the need to have more explanation from a Mathematical point of view about "709 SCENE = Gamma 2.4 with forward OOTF".
2,4/1,96=1,22 (I'm using Comma instead of point - French keyboard)

Forward OOTF means "divide" by 1,22" doesn't it ?
Inverse OOTF means "multiply" by 1,22" doesn't it ?

And this CST

SCR-20231123-hxpk.png (38.84 KiB) Viewed 4537 times

Does "nothing" aka "Multiply" by 1 doesn't it ?
At least that what I saw in fusion

Merge with Difference Apply mode

SCR-20231123-hzbv.png (7.11 KiB) Viewed 4514 times

Thanks in advance

I feel the need to have more explanation from a Mathematical point of view about "709 SCENE = Gamma 2.4 with forward OOTF".
2,4/1,96=1,22 (I'm using Comma instead of point - French keyboard)

Forward OOTF means "divide" by 1,22" doesn't it ?
Inverse OOTF means "multiply" by 1,22" doesn't it ?

Forward OOTF means it applies tonemapping from scene referred space to target a specified display. I this case gamma 2.4 display. This is equivalent to data encoding of rec709 as gamma 2.4 display consumes rec709 scene data.

While power function is a form of simple tonemapping in itself, Resolve does more than that in its OOTF. So forward and inverse OOTFs don't mean only modification of the power function exponent but full forward and reverse tonemapping. Power function can't be used for tonemapping scene-referred data as it either has illogical behavor (outside range 0.0-1.0) or does not match common normalized scene-referred representations for meaningful tonemapping (logarithmic encoding needs S-curve).

Thanks for the reply but I'm struggling to understand
I just need numbers but not precise mathematical formulas

Forward OOTF means it applies tonemapping from scene referred space to target a specified display. I this case gamma 2.4 display.

Forward means from Scene to Display?
Forward means From 1,96 to 2,4 ?
Inverse means from Display to Scene ?
Inverse Means From 2,4 to 1,96 ?
All those are wrong ?

This is equivalent to data encoding of rec709 as gamma 2.4 display consumes rec709 scene data.

Is a CST With input = Rec709 scene & output = Gamma 2,4 (Without Foward OOTF) doing the same job ?

And a CST With input = Rec709 scene & output = Gamma 2,4 & Foward OOTF seems to me redundant. Am I crazy ?

How would you set up a CST to correctly display a Gamma 2,2 file on Gamma 2,6 Display ?

Thanks again
P.S I know how to use a CST the correct way but again it seem completely conter intuitive and I use it "by heart". I wish to understand the logic of the CST

Forward means from Scene to Display?

Yes. From scene referred state to display referred. Also applies picture rendering with tonemapping and whatnot.

Inverse means from Display to Scene ?

Yes. And applies inverse picture rendering, including dynamic range expansion.

Is a CST With input = Rec709 scene & output = Gamma 2,4 (Without Foward OOTF) doing the same job ?
And a CST With input = Rec709 scene & output = Gamma 2,4 & Foward OOTF seems to me redundant. Am I crazy ?

Neither of these is scene referred (thank BMD for the ”scene” naming stupidity in rec709 scene). But... in CST, gamma 2.4 is not the same thing as rec709 gamma 2.4 in the color management. In CST it is the literal gamma 2.4 correction curve as far as I can tell, otherwise it would not change anything (rec709 scene == encoding for gamma 2.4 display == rec709 scene). What the forward transform is supposed to achieve there, I don't know. This stuff makes my head hurt again...

How would you set up a CST to correctly display a Gamma 2,2 file on Gamma 2,6 Display ?

What is a gamma 2.6 display? I don’t know any display standard with gamma 2.6 calibration function. Do you actually mean data encoding here (digital cinema stuff?)

Neither of these is scene referred (thank BMD for the ”scene” naming stupidity in rec709 scene). But... in CST, gamma 2.4 is not the same thing as rec709 gamma 2.4 in the color management. In CST it is the literal gamma 2.4 correction curve as far as I can tell, otherwise it would not change anything (rec709 scene == encoding for gamma 2.4 display == rec709 scene). What the forward transform is supposed to achieve there, I don't know. This stuff makes my head hurt again...

Here is an explanation of my craziness :
CST With input = Rec709 scene & output = Gamma 2,4 (with ou without Foward OOFT) isn't the same as
Color Science = Resolve color managed with Input Color Space= Rec709 scene & outputcolor Space = Rec709Gamma 2,4

Was it ever mentioned here or in the manual ?
Is there other entries in the CST that differs from RCM ColorScience ?
To be explicit : Forward/Inverse OOTF is only for Rec709Scene & gamma 2,4 ?

What is a gamma 2.6 display? I don’t know any display standard with gamma 2.6 calibration function. Do you actually mean data encoding here (digital cinema stuff?)

A Grading monitor for Digital cinema expect to receive via SDI coded values with gamma 2,6.
Thanks for your answers

A Grading monitor for Digital cinema expect to receive via SDI coded values with gamma 2,6.
Thanks for your answers

In the case of grading for cinema, colorists use a true projection system calibrated to gamma 2.6, not a monitor calibrated to gamma 2.6.

A Grading monitor for Digital cinema expect to receive via SDI coded values with gamma 2,6.
Thanks for your answers

In the case of grading for cinema, colonists use a true projection system calibrated to gamma 2.6, not a monitor calibrated to gamma 2.6.

Not wrong

Here is an explanation of my craziness :
CST With input = Rec709 scene & output = Gamma 2,4 (with ou without Foward OOFT) isn't the same as
Color Science = Resolve color managed with Input Color Space= Rec709 scene & outputcolor Space = Rec709Gamma 2,4

Was it ever mentioned here or in the manual ?

Yes, it is in manual. Don't use Color Management in Project Settings for color grading.

Here is an explanation of my craziness :
CST With input = Rec709 scene & output = Gamma 2,4 (with ou without Foward OOFT) isn't the same as
Color Science = Resolve color managed with Input Color Space= Rec709 scene & outputcolor Space = Rec709Gamma 2,4

Was it ever mentioned here or in the manual ?

Yes, it is in manual. Don't use Color Management in Project Settings for color grading.

Thanks
can you tell me witch page speak about that ?

Yes, it is in manual. Don't use Color Management in Project Settings for color grading.

Thanks
can you tell me witch page speak about that ?

I have the same question. I've read through all relevant sections of the manual and I do not see that written anywhere.

Here is an explanation of my craziness :
CST With input = Rec709 scene & output = Gamma 2,4 (with ou without Foward OOFT) isn't the same as
Color Science = Resolve color managed with Input Color Space= Rec709 scene & outputcolor Space = Rec709Gamma 2,4

Was it ever mentioned here or in the manual ?

Yes, it is in manual. Don't use Color Management in Project Settings for color grading.

Thanks
can you tell me witch page speak about that ?

I tried to find it but couldn't find it and now I can't give it more time. Basically, it says that the color space settings in the Project Settings are used, for example, so that the editor (and other people in the editing room) don't have to look at the rushes in the log. For grading, it is correct to always use the tools in Color page - ACES transform, CST, Gammut Mapping, etc.

I did tests on it and the result is really a little different in both cases. It is better in Color page.

It becomes very difficult to understand how Resolve manage colorspaces if
1 - Input colorspace and output colorspace (Rec709 gamma 2,4 for example) doesn't mean the same all across the different tool in the software
2 - the subtleties are not mentioned in the manual

But CST & RCM seems to work the same for colorspaces except for Rec709 don't they ?
I'm focusing now on what is known as "working the same"

Sorry to hop on this late. I have vast history of experience with this problem as a colorist at a bigger post house who gets to work with a high end delivery team. I'll try to post the "solution" as simply as I can.

Almost every consumer device is going to display content at 2.2, despite the fact it was most likely mastered on a 2.4 display. Now you need to know how this content will be viewed.

When we have done Ad content that will only ever be viewed online, we would take this 2.2 remap into consideration.
After I mastered in 2.4 and we were ready to deliver, I would go to my color management. I'd simply switch our output gamma from 2.4 too 2.2. Then on the Delivery page we would tag the export as Color space 709 and Gamma as 709. This gives the 1-1-1.
1-4-1 and 1-2-1 are undefined and inconsistently defined on other systems. 1-1-1 is the only way to be sure it will be read properly on most systems/devices.

So by switching output gamma from the original 2.4 too 2.2 and tagging it as 1-1-1 (709,709) you have successfully tricked consumer devices to show your work as intended.

I'm working on a film which I've graded on a monitor hardware calibrated to Rec.709 gamma 2.4, fed by the output of an Ultrastudio Monitor 3G box. Under the project settings>color management>color space &transforms, color science is set to DaVinciYRGB, Timeline color space is set to Rec.709 Gamma 2.4, and Output color space is set to Same as Timeline.

As a test, I exported a short clip three times. The first version was with the above settings. The second was with Timeline color space set to Rec.709 Gamma 2.2, and the third was with Timeline color space set to Rec.709 (scene). For all three clips, the Output color space was left on "Same as timeline," and in the Deliver page under "Advanced Settings" Color Space Tag was set to Rec. 709 and Gamma Tag was also set to Rec.709. All three clips are properly tagged 1-1-1.

When I compare the three clips, they look absolutely identical. This is true whether I view them on Quicktime, VLC, uploaded to Vimeo and viewed on Firefox or Safari. I don't mean that the clips look the same on all these platforms - they don't, as expected the clips look somewhat higher contrast on VLC than on the other platforms since VLC is presumably not making use of Apple color management. But on any given platform they look identical, and if I load them back into Resolve they look identical.

What am I missing here? How come I'm not seeing any differences when I export my footage using different Timeline color space settings?

I'm using Resolve Studio 18.1.4, on an M1 Mac Mini running OS 12.7.1. My footage is ProRes 422HQ, and I'm exporting the clips as ProRes 422HQ. Thanks for any insights!

Maybe because they are all encoded with same gamma curve?
Viewing device setting (eg. gamma 2.2 or 2.4 etc.) dictates how your footage is going to be shown on final preview.
In other words- to achieve different look you change viewing device setting, not encoding curve which seems to be always the same.
When you grade you use monitor set to specific preview mode- 2.2, BT.1886 etc. This dictates your preview. Later your/consumer screen should use the same preview mode to give expected final result.
On new Macs with reference modes you basically choose desired reference modes and then color sync performs correct math using your 1-1-1 tag as a starting point.
It all works differently than I (and assume many otters) thought. Encoding curve is the same (and should be 'correct' for 1-1-1 tag) and only later by choosing different preview mode you control how footage looks like.

During grade your monitor setting dictates reference look. This is not really controlled by your preset in Resolve- at least not for "family" of preset which share same encoding curve, like you found out.
If you grade eg. for cinema (but tag file 1-1-1) then should give different look as in this case encoding curve will be different.

Does anyone know that encoding curve is definitely the same for all "Rec.709" presets?
End devices don't know if we graded with reference screen set to 2.2 or 2.4 (as they share same encoding curve) - it's up to user to set its screen to desired preview mode. Whole "grading to" starts to have new meaning and it's mainly controlled by setting of our reference screen during grading, not really directly by Resolve preset. Funny enough for cinema, HDR grading this is less confusing as we have 1:1 mapping. It's only Rec.709 with whole 2.2, 2.4 etc. gammas which is messy and confusing.

I'm working on a film which I've graded on a monitor hardware calibrated to Rec.709 gamma 2.4, fed by the output of an Ultrastudio Monitor 3G box. Under the project settings>color management>color space &transforms, color science is set to DaVinciYRGB, Timeline color space is set to Rec.709 Gamma 2.4, and Output color space is set to Same as Timeline.

As a test, I exported a short clip three times. The first version was with the above settings. The second was with Timeline color space set to Rec.709 Gamma 2.2, and the third was with Timeline color space set to Rec.709 (scene). For all three clips, the Output color space was left on "Same as timeline," and in the Deliver page under "Advanced Settings" Color Space Tag was set to Rec. 709 and Gamma Tag was also set to Rec.709. All three clips are properly tagged 1-1-1.

When I compare the three clips, they look absolutely identical...

Because in non-colormanaged project which DavinciYRGB is, whatever you set as timeline or output does not change the actual data encoding, it only modifies the metadata, if even that, and if metadata matches, it shows exactly the same in same software. This is expected. In non-colormanaged mode, whatever the data is, is dumped to the file, there is no "management" (except in some strange undocumented cases).

Basically, it says that the color space settings in the Project Settings are used, for example, so that the editor (and other people in the editing room) don't have to look at the rushes in the log. For grading, it is correct to always use the tools in Color page - ACES transform, CST, Gammut Mapping, etc.

What a joke, a color grading application with so dysfunctional color management that they suggest to not use it... Baselight must be for total amateurs I guess as there color management is actually working and useful.

Because in non-colormanaged project which DavinciYRGB is, whatever you set as timeline or output does not change the actual data encoding, it only modifies the metadata, if even that, and if metadata matches, it shows exactly the same in same software. This is expected. In non-colormanaged mode, whatever the data is, is dumped to the file, there is no "management" (except in some strange undocumented cases).

I agree 100%

95% today's SDR grades are 2.4 (exponent of the power function) based and not a single one is 1.96 based as it's not today's grading standard.

You will be amazed how many are done in 2.2.

Necessary for Web deliveries...

What I usually do for SDR:

Web -> Rec 709 gamma 2,2 (+ tag overwrite in Deliver page to get 1-1-1)
TV -> Rec 709 gamma 2,4 (same as BT-1886, right?)
Cinema -> P3-D65 gamma 2,4 (if RAW footage)

All at 100 nits.

And from all what I read here, I still don't undertand why anyone would use Rec 709 (Scene) for grading.

I'm working on a film which I've graded on a monitor hardware calibrated to Rec.709 gamma 2.4, fed by the output of an Ultrastudio Monitor 3G box. Under the project settings>color management>color space &transforms, color science is set to DaVinciYRGB, Timeline color space is set to Rec.709 Gamma 2.4, and Output color space is set to Same as Timeline.

As a test, I exported a short clip three times. The first version was with the above settings. The second was with Timeline color space set to Rec.709 Gamma 2.2, and the third was with Timeline color space set to Rec.709 (scene). For all three clips, the Output color space was left on "Same as timeline," and in the Deliver page under "Advanced Settings" Color Space Tag was set to Rec. 709 and Gamma Tag was also set to Rec.709. All three clips are properly tagged 1-1-1.

When I compare the three clips, they look absolutely identical...

Because in non-colormanaged project which DavinciYRGB is, whatever you set as timeline or output does not change the actual data encoding, it only modifies the metadata, if even that, and if metadata matches, it shows exactly the same in same software. This is expected. In non-colormanaged mode, whatever the data is, is dumped to the file, there is no "management" (except in some strange undocumented cases).

Thanks so much Hendrik! That makes sense (and, as you say, I am working on a project that is not color-managed). But this raises the question: when project settings>color management>color space & transforms>color science is set to DaVinci YRGB [ie, not color-managed], why is this followed by options for setting "timeline color space" and "output color space" if these settings don't effect anything?? Note that setting for "timeline color space" only appears when Davinci YRGB is selected; the various color-managed color sciences all are accompanied by different sets of options.

EDIT: To answer my own question, after doing some more tests I realized that the "timeline color space" and "output color space" settings DO have an effect on non-color-managed DaVinci YRGB projects IF "Use Mac display color profiles for viewers" is selected in Resolve preferences. I'd previously been viewing with this setting turned off.

95% today's SDR grades are 2.4 (exponent of the power function) based and not a single one is 1.96 based as it's not today's grading standard.

You will be amazed how many are done in 2.2.

Necessary for Web deliveries...

What I usually do for SDR:

Web -> Rec 709 gamma 2,2 (+ tag overwrite in Deliver page to get 1-1-1)
TV -> Rec 709 gamma 2,4 (same as BT-1886, right?)
Cinema -> P3-D65 gamma 2,4 (if RAW footage)

All at 100 nits.

And from all what I read here, I still don't undertand why anyone would use Rec 709 (Scene) for grading.

Because it makes no difference on the export side?

Looks like all Rec.709 presets (2.4, scene etc. ) use same gamma curve for encoding. What really counts is your monitor setting when you grade. Ideally later consumer screen should be set to the same value, but if you used 2.4, but someone's screen is set to 2.2 it still will work. It will just give slightly different look.
My assumption that different Rec.709 presets use different encoding gamma seems to be totally wrong. No idea why no one every tried to explain it? Maybe I'm wrong again, but this time looks like not. Encoding gamma for all 'Rec.709' presets is the same. Industry started to use different reverse gamma because at the beginning they did not define spec for viewing devices. Then preview technology changed, which made it even worse. Now not a single(?) for Rec.709 "setting" is 1:1, so encoding and decoding curves don't cancel each other.
Based on reports from this and other threads eg. 2.4 gamma in Resolve means nothing different than eg. 'scene' when it comes to export. Both will use same encoding curve (1.96 gamma based) and only later depending on used device decoding gamma is eg 2.2 or 2.4 based. This is why Apple's reference BT.1886 mode uses 1.22 'gamma boost'. This is 2.4/1.96, so color sync engine takes 1-1-1 tag which tells it encoding gamma was 1.96 (this is confirmed as tagging file 1-2-1+ gamma tag=1.96 gives exactly same preview).
With reference screens/TVs story is even simpler- they apply any reverse gamma which user chosen in the settings. Today in new TVs BT.1886 seems to be the default one, so it's expected to grade on screen set to this standard (which is referred as 2.4 gamma quite often). It doesn't mean that file coming out of Resolve is 2.4 gamma encode- it's not, hence 1-2-1+2.4 gamma tag (which I suggested in the past) is actually incorrect.
It all makes (now) way more sense, including introduction of Apple's reference modes and 'values' behind them (eg. mysterious 1.22 boost). It also explains why any grading done on reference screens is fine- because key element is setting in viewing device during grading. Tag may be also important, but key element is correct preview during grading (hence new Apple ref modes for their devices). If Resolve properly passes data to the "screen" now with BT.1886 ref mode during grading it all should work fine and match (gamma wise) preview with BM card on ref screen set to BT.1886.

Because it makes no difference on the export side?

Looks like all Rec.709 presets (2.4, scene etc. ) use same gamma curve for encoding. What really counts is your monitor setting when you grade. Ideally later consumer screen should be set to the same value, but if you used 2.4, but someone's screen is set to 2.2 it still will work. It will just give slightly different look.
My assumption that different Rec.709 presets use different encoding gamma seems to be totally wrong. No idea why no one every tried to explain it? Maybe I'm wrong again, but this time looks like not. Encoding gamma for all 'Rec.709' presets is the same. Industry started to use different reverse gamma because at the beginning they did not define spec for viewing devices. Then preview technology changed, which made it even worse. Now not a single(?) for Rec.709 "setting" is 1:1, so encoding and decoding curves don't cancel each other.
Based on reports from this and other threads eg. 2.4 gamma in Resolve means nothing different than eg. 'scene' when it comes to export. Both will use same encoding curve (1.96 gamma based) and only later depending on used device decoding gamma is eg 2.2 or 2.4 based. This is why Apple's reference BT.1886 mode uses 1.22 'gamma boost'. This is 2.4/1.96, so color sync engine takes 1-1-1 tag which tells it encoding gamma was 1.96 (this is confirmed as tagging file 1-2-1+ gamma tag=1.96 gives exactly same preview).
With reference screens/TVs story is even simpler- they apply any reverse gamma which user chosen in the settings. Today in new TVs BT.1886 seems to be the default one, so it's expected to grade on screen set to this standard (which is referred as 2.4 gamma quite often). It doesn't mean that file coming out of Resolve is 2.4 gamma encode- it's not, hence 1-2-1+2.4 gamma tag (which I suggested in the past) is actually incorrect.
It all makes (now) way more sense, including introduction of Apple's reference modes and 'values' behind them (eg. mysterious 1.22 boost). It also explains why any grading done on reference screens is fine- because key element is setting in viewing device during grading. Tag may be also important, but key element is correct preview during grading (hence new Apple ref modes for their devices). If Resolve properly passes data to the "screen" now with BT.1886 ref mode during grading it all should work fine and match (gamma wise) preview with BM card on ref screen set to BT.1886.

Thanks for all the infos
I've read it 3 times, And I still don't understand all . it's me!!
I'll try again, and probably ask some clarifications

I think it's closer to "final explanation", but not fully there yet.
We have new questions now