Final Explanation of Gamma and Color Shift Problems

The tagging system of the future should describe how or what the file is to be viewed through, not what it is. That tag would tell the monitor, this rec709 mastered file, should be “viewed through” a rec 709 2.4 gamma monitor. Then the monitor would switch to a 3D LUT calibration for rec709 2.4 gamma.

Imho this is backwards logic. Metadata about the file must describe the file itself, not some kind of assumption of file usage.

How can real nature be 1.96 if you graded file to 2.4 and just tagged 1-1-1? Real nature is based on Resolve setting, not what export tags says as you can make it say anything .

This is where the mess comes in. Grading a file "to 2.4" applies implicit BT.709 OETF encoding function to the data, whether technically or simply by user's bias of "what looks right". And this function is the one that can be approximated with gamma correction curve with power of 1.96.

A simple test question in this argumentation is this: is end to end gamma greater than 1.0 desirable in the viewing env accompanying BT.1886 display and if so, what does the encoding function have to be to achieve that on a BT.1886 (or simplified gamma 2.4) calibrated display.

How can real nature be 1.96 if you graded file to 2.4 and just tagged 1-1-1? Real nature is based on Resolve setting, not what export tags says as you can make it say anything .

This is where the mess comes in. Grading a file "to 2.4" applies implicit BT.709 OETF encoding function to the data, whether technically or simply by user's bias of "what looks right". And this function is the one that can be approximated with gamma correction curve with power of 1.96.

Is it?
I thought 1.96 is just reverse of Rec.709 old recording device spec, not something "current" as it says here:
https://en.wikipedia.org/wiki/Rec._709
I also thought 1.96 is applied when you grade to Rec.709-A, not to 2.4 in Resolve?

Rec.709 (1-1-1) or 1-2-1+ 1.96 gamma for OSX color sync gives exactly same end results as final preview goes.
2.4 grading with Resolve managed preview gives same end result as 1-2-1 with 2.4 gamma tag for preview in QTX.
This somehow negates what you're saying about 1.96 (at least for me).

This recording device spec is based on the logic that combination of rec709 OETF + gamma 2.4 calibrated display gives appropriate end-to-end gamma of ~1.2. The necessity for end-to-end gamma greater than one has gone nowhere, it is paramount to produce good contrast in dim surround. And this is why data encoding with 1/2.4 exponent power function isn't going to cut it, whatever the metadata or tags say. This encoding compounded with the EOTF of display won't produce proper result: pow(pow(in, 1/2.4), 2.4) == 1.0. Thus, if color management doesn't take care of it, user does, unknowingly, by increasing the contrast of the image, screwing with it until this appropriate end-to-end gamma is approximated.

This is rather different subject all together.

I'm just saying that files exported with 2.4 gamma vs. Rec.709-A out of Resolve are very different so they are definitely not encoded with same gamma.
As far as I remember in Dolby, Sony etc. reference monitors you had pure 2.4 setting and this what studio use/used. What is really behind those settings I have no idea.

It isn't as, this is the basis for first understanding what the rec709 data encoding actually is, and then tagging it appropriately. Whether these tags are actually interpreted correctly AND system makes logical decisions based on that interpretation is another story and half of the mess. But proper description of the data is the foundation of any kind of color management.

2.4 grading with Resolve managed preview gives same end result as 1-2-1 with 2.4 gamma tag for preview in QTX.
This somehow negates what you're saying about 1.96 (at least for me).

Have you tested what the actual encoding function is in Resolve if you select "gamma 2.4"? It could be called "sweet tv" for all we care, what matters is what it actually does internally.

All what most people care atm. is to be able send file to Vimeo/YT and have same preview as the starting file. This is not the case atm. due to tags mess. Actual accuracy of this preview (monitor, surroundings impact etc.) is yet another story which is faaaar more complex.

2.4 grading with Resolve managed preview gives same end result as 1-2-1 with 2.4 gamma tag for preview in QTX.
This somehow negates what you're saying about 1.96 (at least for me).

Have you tested what the actual encoding function is in Resolve if you select "gamma 2.4"? It could be called "sweet tv" for all we care, what matters is what it actually does internally.

No idea. I just care it's current standard and in most cases a setting to be used (mandated by the client).
If 2.4 exported file overwritten with 1-2-1+ 1.96 tag gives different preview than Rec.709-A (which I think been confirmed it's 1.96) then it's not going to be 1.96. That much can be said.

From the thread about reference modes you may get to conclusion that Apple expects file to be 1.96 encoded and have 1-1-1 tag, because SDR reference preset has 1.22 so called boost, which would give final 2.4 gamma. Problem is then that if file is not 1.96 based and 1-1-1 tagged as Apple mandates you will get bad preview unless you create own ref mode without boost setting. At the end it should be possible to have accurate gamma/gamut preview on internal screen using reference modes, but it needs measurement and validation first as things are no so obvious as one would think.

If 2.4 exported file overwritten with 1-2-1+ 1.96 tag gives different preview than Rec.709-A (which I think been confirmed it's 1.96)

Now here's a funky piece, I can't see how Rec.709-A actually has 1.96 gamma correction curve applied in Resolve export. Here's what I did: Resolve colormanaged project, SDR rec709 mode, output color space set to Rec.709-A. Exporting a linear ramp (true linear, read into working space as-is). I can't find any existing logical gamma curve that matches the result in this case. Might be due to tonemapping in action but here's the thing: both Rec.709 (Scene) and Rec.709 Gamma 2.4 have matching gamma curve and surprise-surprise, it is the BT.709 OETF encoding curve (with linear toe and gamma of 0.45) for BOTH. They are identical data wise.

Rec.709 (1-1-1) or 1-2-1+ 1.96 gamma for OSX color sync gives exactly same end results as final preview goes.
2.4 grading with Resolve managed preview gives same end result as 1-2-1 with 2.4 gamma tag for preview in QTX.
This somehow negates what you're saying about 1.96 (at least for me).

Can you elaborate "1-2-1 with 2.4 gamma tag"
Thanks

If 2.4 exported file overwritten with 1-2-1+ 1.96 tag gives different preview than Rec.709-A (which I think been confirmed it's 1.96)

Now here's a funky piece, I can't see how Rec.709-A actually has 1.96 gamma correction curve applied in Resolve export. Here's what I did: Resolve colormanaged project, SDR rec709 mode, output color space set to Rec.709-A. Exporting a linear ramp (true linear, read into working space as-is). I can't find any existing logical gamma curve that matches the result in this case. Might be due to tonemapping in action but here's the thing: both Rec.709 (Scene) and Rec.709 Gamma 2.4 have matching gamma curve and surprise-surprise, it is the BT.709 OETF encoding curve (with linear toe and gamma of 0.45) for BOTH. They are identical data wise.

So Rec.709 Scene and 2.4 are the same?
Rec.709-A is something else.
Don't like when 2 things are the same but have different name, although may understand why it's there.

Rec.709 (1-1-1) or 1-2-1+ 1.96 gamma for OSX color sync gives exactly same end results as final preview goes.
2.4 grading with Resolve managed preview gives same end result as 1-2-1 with 2.4 gamma tag for preview in QTX.
This somehow negates what you're saying about 1.96 (at least for me).

Can you elaborate "1-2-1 with 2.4 gamma tag"
Thanks

Custom tag which allows you to write info about pure gamma curve. It's read by OSX color sync and based on it converted to display profile. Resolve flags files this way for 2.4 grades, but you can play with it using Mogurenko tool.

So Rec.709 Scene and 2.4 are the same?
Rec.709-A is something else.
Don't like when 2 things are the same but have different name, although may understand why it's there.

Yes, my impression from my tests is that they are the same data wise (actual image data, not metadata) and the reason is that some time ago BMD ”discovered” that encoding data with gamma correction for 2.4 is nonsensical if targeting rec709 displays but since everyone and their aunt keep insisting this is a thing, they kept the notation in colormanaged system, while internally mapping it to actual useful encoding function. It makes no difference how it is called in non-CM system as at best it can only influence tagging but in actual CM it does make a difference as transforms need to be applied and these are hard tangible things.

What exactly Rec.709-A is, no idea, closest I find to it is gamma correction for 1.66 and I have to admit that previously my impression was that -A variant was only about tagging, but apparently that impression was wrong.

PS. If I write ”apply gamma correction for X” it means applying power function with exponent 1/X. Applying gamma X means exactly that, applying power function with exponent X.

I talked about how all the tagging modes are assigned in a previous post. It depends on what color science setting you use. But when using RCM and selecting the automatic SDR setting, guess what, resolve spits out the correct 1-1-1 tags. If you uncheck automatic and even select custom, you can see that it automatically has set up rec709 (scene) for output color space. Makes sense, because this is how rec709 works. Hendrik is correct. Also, rec709 is actually scene referred, read the itu spec. It does not have a display EOTF applied. And the math doesn’t add up if you apply an arbitrary 2.4 gamma curve on top of the 1.96 rec709 OETF, because then if you watched on a correct rec709 2.4 gamma, you would be adding yet another gamma curve and the image will look dark. When you use manual color management in resolve, the output color space does not specify the monitor for rec709, it specifies the file.

Hendrik is right that, somewhere along the way, people (even Blackmagic themselves), keep telling others to setup their projects for rec709 2.4gamma, which is not how it works. But now resolve finally sets up rec709 correctly if you use RCM SDR mode. Again, if manually setting up with davinci yrgb, you set up rec709 scene as output color space.

Not sure why you would not setup as 2.4 gamma? I don't necessarily mean that it has to apply 2.4 encoding, just that it's correct for today's displays set to BT.1886.
Are you talking latest Resolve?
When you use those BM presets for SDR how does it set it now? You go custom and then you can see what it's set there. Old presets were far from ideal. Is it changed (I don't have latest Resolve)?

Because of the tag? In current post world tag is about meaningless when passing masters in the chain as no one uses it. Also- it can be freely changed without a problem.

Also Resolve should finally use proper naming as BT.1886 when it's appropriate, like all others tool do now.

Because output color space is not defining monitor. It’s defining rec709 source output color space. The monitor defines the monitor color space. It’s that simple. 2.4 doesn’t enter the equation until you view 1.96 file on monitor.

And yes I’m using resolve studio 18.6.2.

Yes, but you need a setting which is correct for today's monitors set to BT.1886 hence 2.4 gamma preset I assume. I argue that you don't create a file for sake of itself, but you create files for specific delivery which defines viewing point- cinema, Blu-ray etc. So you need setting which tells you what what you are targeting. It should be correct and you may not know/care what it's actually behind given setting.

Resolve is a mess when it comes to specs, naming convention etc. It should be all fixed and corrected as per today's standards. Even use of Rec.2020 is in some places if I remember correctly wrong as it should be Rec.2100. It may be basically same things, but if a reference tool is messy then how you want to rest to be correct and understand it? Look at Baselight.

Rec2020 and Rec2100 are not the same thing. You can have a file in Rec2020 that is not HDR. However, Rec2100 does use Rec2020.

Go into Resolve and turn off "Use Mac display color profiles" in preferences and change your project color science to DaVinci YRGB. Now, change the output color space to anything you like, nothing changes! You can select XYZ or ACES for instance and your clips don't change in appearance. The only thing that will change is the tagging associated with the file. The output colorspace doesn't seem to do anything other than that in a non-color managed workflow. Even if it's describing the output monitor, it's certainly not applying any transform to the file.

Tell this to BM which seems to use both as they would mean 100% the same (unless it's changed in latest version).

If you have monitor which is calibrated to a standard then you can turn off "Use Mac display color profiles" as then Resolve just pushes RGB data to output and your monitor takes care of applying correct gamma.
For internal displays this is not so easy. You either need to use reference modes (which switch monitor to correct gamam/gamut) or turn on "Use Mac display color profiles" so then color sync converts Resolve output data to a monitor profile.

I talked about how all the tagging modes are assigned in a previous post. It depends on what color science setting you use. But when using RCM and selecting the automatic SDR setting, guess what, resolve spits out the correct 1-1-1 tags. If you uncheck automatic and even select custom, you can see that it automatically has set up rec709 (scene) for output color space. Makes sense, because this is how rec709 works. Hendrik is correct. Also, rec709 is actually scene referred, read the itu spec. It does not have a display EOTF applied. And the math doesn’t add up if you apply an arbitrary 2.4 gamma curve on top of the 1.96 rec709 OETF, because then if you watched on a correct rec709 2.4 gamma, you would be adding yet another gamma curve and the image will look dark. When you use manual color management in resolve, the output color space does not specify the monitor for rec709, it specifies the file.

Hendrik is right that, somewhere along the way, people (even Blackmagic themselves), keep telling others to setup their projects for rec709 2.4gamma, which is not how it works. But now resolve finally sets up rec709 correctly if you use RCM SDR mode. Again, if manually setting up with davinci yrgb, you set up rec709 scene as output color space.

Rendered REC 709 SCENE is Gamma 2.4 the only difference being that the NCLC Tags are 1-1-1 and the VUI tags are BT709/BT709/BT709.

REC 709 Gamma 2.4 gets NCLC tags of 1-2-1 and VUI tags of BT709/BT709/unknown.

The actual rendered video CODE VALUES are identical. The only difference is how some CM systems might interpret them.

Setting Rec 709 SCENE in a NON Color managed project does not = RCM.. It only sets tagging and not encoded code values of the video stream. The encoded values must be set via CST or possibly a LUT. There is no 709 SCENE value in a CST per se.. But it is REC709 Transfer without the Forward OOTF applied. Gamma 2.4 will get the OOTF.

REC 709 SCENE is Gamma 2.4 the only difference being that the NCLC Tags are 1-1-1 and the VUI tags are BT709/BT709/BT709.

REC 709 Gamma 2.4 gets NCLC tags of 1-2-1 and VUI tags of BT709/BT709/unknown.

The actual video CODE VALUES are identical. The only difference is how some CM systems might interpret them.

This is incorrect.

Rec.709 Scene is the ITU-R BT.709 transfer function.

Gamma 2.4 is a pure power law function.

BT.1886 = Gamma 2.4 when black = 0 and white = 100 cd/m2 respectively.

A file exported as Gamma 2.4 has the Transfer Characteristic set to "2" which is "Unspecified". It's up to the host application to interpret this file for viewing. YouTube for example assumes it to be tagged as ITU-R BT.709 as do many other players.

The confusion arises because at some point during the CRT era a group of engineers decided that the EOTF and inverse OETF functions should not be equal to one another due to human "perception". This is what we call "System Gamma". An ITU-R BT.709 encoded video is therefore gamma corrected as Gamma 2.4 (BT.1886) on TV screens... which essentially means it's not a straight linear System Gamma.

Unfortunately, much like the NTSC frame-rate hacks that have persisted even after technical limitations were removed, we are stuck with a lot of legacy from a bygone era.

The irony of this whole topic is that Gamma 2.2 encoded content does not suffer from the same "system gamma" issues as the EOTF and inverse OETF is always a system gamma of 1.

The caveat here is that Resolve's RCMv2 messes things up when DRT is set to "DaVinci" as it applies an arbitrary system gamma "correction" to Gamma 2.2 and 2.6 encoded files when it has no reason to. I've mentioned this before on the forum but it seems most people don't know and therefore don't care about what happens under the hood.

Yes, but you need a setting which is correct for today's monitors set to BT.1886 hence 2.4 gamma preset I assume. I argue that you don't create a file for sake of itself, but you create files for specific delivery which defines viewing point- cinema, Blu-ray etc. So you need setting which tells you what what you are targeting.

And if display differs from that (on Apple devices for example), how is the target helping? It adds another potentially error prone step of interpretation from target description to actual source colorspace, to be able to actually do a meaningful transform for new target from that colorspace.

You don’t care if display is inaccurate. Not your problem. If display is not accurate then it doesn’t matter what you do - end result will be inaccurate anyway :p
You grade to a standard/delivery point specified by client, get approval on your ref screen and that’s about it for your job. Rest is not your responsibility otherwise you would bankrupt after 1st job.
No one grades to ‘underneath’ gamma hidden in some spec or tries to correct it because screen is not going to be correctly calibrated.
Today’s typical spec information are BT.1886, Rec.709, Rec.709 2.4 gamma or P3-DCI etc.

Only exception: you grade for a client who wants it for a specific brand and type of screen, like in an exhibition or permanent installation.
In that case, a sample provided and connected to a 'pure' signal out of DR can be used for approval (under appropriate lighting, of course).

You don’t care if display is inaccurate. Not your problem. If display is not accurate then it doesn’t matter what you do - end result will be inaccurate anyway :p

Question is not about accuracy (measuring that from within the system is impossible anyway), it is about knowing the content of the file to actually do something useful with it. These days it is not a given that a file mastered for target X is always, with no exceptions only displayed on target X. If this were the case this topic wouldn't exist. And again, it is not about grading for clients wonky display, no-one should care about that, not our job.

The source of the gamma shift mess is exatly this: metadata states something about the file, some softwares interpret it as description of target display, some as description of mastering display, some as description of source data, some don't use the metadata tag at all. And underneath, some softwares encode it with gamma X, some with gamma Y, for the exact same tag.

If I tag a file as 1-2-1 with gamma 2.2, is it stating that file has power function 1/2.2 applied on its data (encoding function) or it targets display with 2.2 EOTF? Does the same interpretation apply if it is 1-2-1 and 2.4? If it is 1-2-1 and 1.96? What does gamma tag "linear" mean? There are no displays with linear EOTF setup...

The irony of this whole topic is that Gamma 2.2 encoded content does not suffer from the same "system gamma" issues as the EOTF and inverse OETF is always a system gamma of 1.

It's not only about content though, sRGB has different expectations about view environment, display calibration and somewhat also actual picture content. If the expected env were the same dim surround it would also have to produce system gamma > 1.0 through some mechanism either at the display end or in data encoding.

Dim surround:
If BT.709 encoded image is displayed on BT.1886 calibrated display it produces system gamma ~1.2
If sRGB encoded image is displayed on BT.1886 calibrated display it produces system gamma ~1.1

Bright surround:
If BT.709 encoded image is displayed on sRGB calibrated display it produces system gamma ~1.12
If sRGB encoded image is displayed on sRGB calibrated display it produces system gamma 1.0

In both cases, the encoding of data modifies the end to end gamma according to expected content of the imagery. sRGB's primary intent was graphics where absolute luminance aligns with the luminance of the display, thus lower system gamma is fine. In case of BT.709 imagery usually contains natural scenes with much higher absolute luminance. To represent that in a pleasing way on low-luminance display, higher system gamma is necessary and is also produced in both cases.

Interesting question raises about sRGB in case of photos, my current admittedly uneducated understanding is that in this case same luminance levels mismatch problem arises and it is solved in the capture device (camera) by applying implicit picture rendering that accounts for that.

REC 709 SCENE is Gamma 2.4 the only difference being that the NCLC Tags are 1-1-1 and the VUI tags are BT709/BT709/BT709.

REC 709 Gamma 2.4 gets NCLC tags of 1-2-1 and VUI tags of BT709/BT709/unknown.

The actual video CODE VALUES are identical. The only difference is how some CM systems might interpret them.

This is incorrect.

Rec.709 Scene is the ITU-R BT.709 transfer function.

Gamma 2.4 is a pure power law function.

BT.1886 = Gamma 2.4 when black = 0 and white = 100 cd/m2 respectively.

A file exported as Gamma 2.4 has the Transfer Characteristic set to "2" which is "Unspecified". It's up to the host application to interpret this file for viewing. YouTube for example assumes it to be tagged as ITU-R BT.709 as do many other players.

The confusion arises because at some point during the CRT era a group of engineers decided that the EOTF and inverse OETF functions should not be equal to one another due to human "perception". This is what we call "System Gamma". An ITU-R BT.709 encoded video is therefore gamma corrected as Gamma 2.4 (BT.1886) on TV screens... which essentially means it's not a straight linear System Gamma.

Unfortunately, much like the NTSC frame-rate hacks that have persisted even after technical limitations were removed, we are stuck with a lot of legacy from a bygone era.

The irony of this whole topic is that Gamma 2.2 encoded content does not suffer from the same "system gamma" issues as the EOTF and inverse OETF is always a system gamma of 1.

The caveat here is that Resolve's RCMv2 messes things up when DRT is set to "DaVinci" as it applies an arbitrary system gamma "correction" to Gamma 2.2 and 2.6 encoded files when it has no reason to. I've mentioned this before on the forum but it seems most people don't know and therefore don't care about what happens under the hood.

No it is not incorrect. Not in the context of using stock RCM or standard CST stack to render, which i was replying too.... 709 SCENE is the DR REC709 Transfer without Forward OOTF, and equals Gamma 2.4 with forward OOTF. Render them both out…. Use a SMPTE bar, Grey scale ramp and a still.…. Load both onto a timeline…. Make sure there is no color management. And A/B difference wipe… you will get BLACK.. they are identical. ITU-R BT.709 has no defined transfer function for EOTF, 1886 adds one for 2.4.

At face value you are correct.. At the core they are different. However we are talking about files rendered from Resolve and how gamma ends up practically speaking.... A CST will default REC709 Transfer to no Forward OOTF but the Gamma 2.4 will have the OOTF applied... This yields an identical output from the Encoded file.

Custom tag which allows you to write info about pure gamma curve. It's read by OSX color sync and based on it converted to display profile. Resolve flags files this way for 2.4 grades, but you can play with it using Mogurenko tool.

I learn something
Thanks

If I tag a file as 1-2-1 with gamma 2.2, is it stating that file has power function 1/2.2 applied on its data (encoding function) or it targets display with 2.2 EOTF? Does the same interpretation apply if it is 1-2-1 and 2.4? If it is 1-2-1 and 1.96? What does gamma tag "linear" mean? There are no displays with linear EOTF setup...

Well - if OSX color sync uses this to perform conversion to a display profile then this info describes source not target. This is my logic. How can it be target info if you use it to convert to another target display ? It makes no sense then.

If you read the DR manual it mentions how the rec709 is handled using RCM page 220 in latest manual.

I wouldn’t worry about NCLC tags too much. 1-1-1 or 1-2-1 is probably not going to matter, because it either gets converted or ignored. The whole tagging system is F’d and most likely can’t have a real solution. Maybe in the future, we will see an automatic 3D lut based color management system and move away from ICC / color sync approach.

Or everybody will go HDR, where things work correctly.

Possibly the tags will work, but HDR is a mess right now because there isn't a true reference monitor yet, correct viewing / room conditions are way more important than with SDR, and we have multiple types of HDR out in the wild. Although Rec.2020/ PQ (Dolby Vision) will probably become the most ubiquitous. Then, once we start to come to an agreement, we will start hearing about 16k tvs and how our lives will be forever changed, as long has we sit 1cm away from the screen

We'll all have some googles on our faces by then and only meet each other in VR…

We'll all have some googles on our faces by then and only meet each other in VR…

Maybe so haha


I did just recently go to an older iMac (2019, running Catalina (10.15.7) and Resolve (17.4.3). The behavior of the viewer window and QuickTime, with "Use Mac Color Profiles..." turned off, 1-1-1 tags don't match, as they do on my newer Mac Studio system. So something has obviously been changed. The Mac image looks brighter and more washed out. FWIW, this might be why some are swearing by 1-2-1 tags. But the newer system the 1-1-1 tags look the same, as I've mentioned so many times. So it might be worthwhile for everybody to list their software and hardware setups, or else we are all potentially seeing very different outcomes with the same settings. Clearly this has already been brought up by a few here, but it's even clearer to me now, that this whole tagging thing is really non-sensical, messed up and mostly useless.

I wouldn’t worry about NCLC tags too much. 1-1-1 or 1-2-1 is probably not going to matter, because it either gets converted or ignored. The whole tagging system is F’d and most likely can’t have a real solution. Maybe in the future, we will see an automatic 3D lut based color management system and move away from ICC / color sync approach.

So to add this this... I have been doing a bunch of output testing, and looking at how certain platforms like YouTube Handle them ... What adds to all of this mess is that some encoder TAGS are not consistent across platforms.. MAC vs PC tag outputs from Resolve are not 1:1 in all cases...

The thing I am really trying to get across is the are NCLC tags and Bitstream tags like VUI. These both come into play depending on the CM system.

Some interesting finds:

MAC Gamma 2.2 ProRes 422 HQ - Gets NCLC tags set to 1-4-1, and VUI tags set as bt709/bt709/bt470m

MAC Gamma 2.2 H265 - Gets NCLC tags set to 1-4-1, and VUI tags set as bt709/bt709/UNKNOWN

PC Gamma 2.2 H265 - Gets NCLC tags set to 1-4-1, and VUI tags set as bt709/bt709/bt470m

When uploading to Youtube - It reads both sets of tags and decides whether or not to apply a 2.2 to 2.4 OOTF to the encode.

Now this yields a gamma shift to the correctly tagged VUI MAC/PC versions, but the MAC H26x VUI tagged as "unknown" will not receive this OOTF transform even though its NCLC tag is 1-4-1. The incorrectly tagged version will look correct.

YouTube converts NCLC to 1-1-1 on output encode.

Now...

If you tag these encodes as 1-1-1 prior to uploading to YouTube.... They will not get the OOTF applied.

Madchiller

Haven’t tested YouTube, but Vimeo converts to 1-1-1. This will allow a monitor correctly 3D lut calibrated to rec709 2.4 d65 100nits, to look identical to resolve out into ultra studio into 3D lut calibrated rec709 monitor. So that’s why I use 1-1-1 tags. It allows users with monitors set up correctly calibrated to see what I saw in my room. Hope that makes sense.

Madchiller

Haven’t tested YouTube, but Vimeo converts to 1-1-1. This will allow a monitor correctly 3D lut calibrated to rec709 2.4 d65 100nits, to look identical to resolve out into ultra studio into 3D lut calibrated rec709 monitor. So that’s why I use 1-1-1 tags. It allows users with monitors set up correctly calibrated to see what I saw in my room. Hope that makes sense.

Makes sense
How have you created this 3D Lut ?
From a color Space transform node ?
Thanks

Olivier, the 3D lut I’m speaking of is one that is inside the monitor. It has nothing to do with the processing inside of Resolve. My monitor is a Flanders DM240 and has these luts built in from the factory. You can also recalibrate using several methods. But they have one called Autocal which allows you to use a colorimeter with matrix designed for the monitor, that then recalibrates all of the built in luts. This is the simplest and most affordable way to keep your monitor in spec. There are other more complex and expensive ways to calibrate, which would potentially yield more accurate results. But the people at Flanders told me, visually it wouldn’t look different. So there is a point with calibration that exceeds human perception, but reads better on meter.

Once your monitor is setup correctly, you can color grade your footage using any number of methods to transform it into a pleasing image on the display.

Madchiller

Haven’t tested YouTube, but Vimeo converts to 1-1-1. This will allow a monitor correctly 3D lut calibrated to rec709 2.4 d65 100nits, to look identical to resolve out into ultra studio into 3D lut calibrated rec709 monitor. So that’s why I use 1-1-1 tags. It allows users with monitors set up correctly calibrated to see what I saw in my room. Hope that makes sense.

Yes. This could make sense for a few reasons. However there is some important data missing here. What was the source file encoding as, and what what the source file Tagging to start?

Assuming Encoded as 709 2.4 - I would need to test Vimeo... but YouTube expects and tries to deliver 2.4 - so it does not reencode 2.4 files with a new OOTF regardless of NCLC tags being 1-1-1 or 1-2-1.. It will however change the NCLC tags to 1-1-1 either way. If you download the file post YouTube Encode and compare on the Resolve timeline... You will see they are still in fact still the same.

With the Gamma 2.2 with proper bt470m VUI tags, as per my post above... The post YT encoded files have a OOTF applied and when downloaded and compared will be notably darker. However the G2.2 encoded files tagged as 1-1-1 before upload will not get the OOTF on YouTube encode, and will look 1:1 when displayed on a Gamma 2.2 display, and when downloaded will still be 1:1 as compared on the DR TL.

So if You have an encoded 2.4 file coming from Vimeo that is providing a 1-1-1 tag and being displayed on a 709 2.4 monitor ... CM has nothing to do.. It should just send to display as 1:1 with no system OOTF.

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.

Here's something to take into consideration. Why would consumer devices show all content remapped too 2.2? This is because they assume consumers are in a well light environment while viewing. So you can actually look at the remap as your friend since you want the image to look accurate in a well light environment.

After years of testing, we personally look at this remap as our friend. We no longer change our 2.4 gamma too 2.2. We simply tag our 2.4 footage as 709 709/ 1-1-1.

something to note for web uploads too platforms like Vimeo or YouTube is to understand it will compress your footage and retag it no matter what format you upload. So for the best results get your 2.4 image tagged as 709 scene (1-1-1) and export as ProRes LT. Upload that ProRes LT 1-1-1 file too the platform. In our experience doing this gets the image looking consistent on any device or browser.

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.

Here's something to take into consideration. Why would consumer devices show all content remapped too 2.2? This is because they assume consumers are in a well light environment while viewing. So you can actually look at the remap as your friend since you want the image to look accurate in a well light environment.

After years of testing, we personally look at this remap as our friend. We no longer change our 2.4 gamma too 2.2. We simply tag our 2.4 footage as 709 709/ 1-1-1.

something to note for web uploads too platforms like Vimeo or YouTube is to understand it will compress your footage and retag it no matter what format you upload. So for the best results get your 2.4 image tagged as 709 scene (1-1-1) and export as ProRes LT. Upload that ProRes LT 1-1-1 file too the platform. In our experience doing this gets the image looking consistent on any device or browser.

I agree with the vast majority of this. For all online deliveries I target and Encode Gamma 2.2 as well, and generally force NCLC tagging to 1-1-1. One note.. I may be reading it incorrectly or your wording if off... 1-4-1 is not "UNDEFINED"/UNKNOWN.. it is BT470M. However some encoders will tag the bitstream (VUI) as "unknown" which is technically incorrect or at least inconsistent.

Otherwise your post is very much aligned with my workflow for Gamma 2.2

You read that correctly but I do admit it doesn't make a whole lot of sense. That's because it doesn't make a whole lot of sense in the real world. 1-4-1 is defined in some places and undefined in others. That's why we all like the safety of 1-1-1 tagging.

I used to upload Rec.709 gamma 2.2 videos tagged 1-1-1 to Vimeo and YouTube and for general web deliveries.

I keep a Rec.709 gamma 2.4 tagged 1-2-1 (as I grade my project on a monitor calibrated to gamma 2.4) even if the "2" is undefined. Maybe I should consider using the tag 1-1-1 for my gamma 2.4 exports too...

You read that correctly but I do admit it doesn't make a whole lot of sense. That's because it doesn't make a whole lot of sense in the real world. 1-4-1 is defined in some places and undefined in others. That's why we all like the safety of 1-1-1 tagging.

Technically imho it should never be defined as UNKNOWN... and always as bt470m. However I have noticed as i posted earlier, that some encoders do not tag the bitstream tags consistently. This only goes to add to all the mess.

Why 1-4-1? 4 is rather useless value (bt470m).

Here's something to take into consideration. Why would consumer devices show all content remapped too 2.2? This is because they assume consumers are in a well light environment while viewing. So you can actually look at the remap as your friend since you want the image to look accurate in a well light environment.

After years of testing, we personally look at this remap as our friend. We no longer change our 2.4 gamma too 2.2. We simply tag our 2.4 footage as 709 709/ 1-1-1.

100% YES to this! When not in a dim surround environment by using a 0.2 gamma conversion before the export, they're just going to be perceived as too dark AND if someone actually has a proper rec709 2.4 setup, it will be wrong.

I also agree with you about 1-1-1 being a standard tag and not having issues with software misinterpreting.

Madchiller

Haven’t tested YouTube, but Vimeo converts to 1-1-1. This will allow a monitor correctly 3D lut calibrated to rec709 2.4 d65 100nits, to look identical to resolve out into ultra studio into 3D lut calibrated rec709 monitor. So that’s why I use 1-1-1 tags. It allows users with monitors set up correctly calibrated to see what I saw in my room. Hope that makes sense.

Yes. This could make sense for a few reasons. However there is some important data missing here. What was the source file encoding as, and what what the source file Tagging to start?

Assuming Encoded as 709 2.4 - I would need to test Vimeo... but YouTube expects and tries to deliver 2.4 - so it does not reencode 2.4 files with a new OOTF regardless of NCLC tags being 1-1-1 or 1-2-1.. It will however change the NCLC tags to 1-1-1 either way. If you download the file post YouTube Encode and compare on the Resolve timeline... You will see they are still in fact still the same.

With the Gamma 2.2 with proper bt470m VUI tags, as per my post above... The post YT encoded files have a OOTF applied and when downloaded and compared will be notably darker. However the G2.2 encoded files tagged as 1-1-1 before upload will not get the OOTF on YouTube encode, and will look 1:1 when displayed on a Gamma 2.2 display, and when downloaded will still be 1:1 as compared on the DR TL.

So if You have an encoded 2.4 file coming from Vimeo that is providing a 1-1-1 tag and being displayed on a 709 2.4 monitor ... CM has nothing to do.. It should just send to display as 1:1 with no system OOTF.

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'm starting to see that ColorSync / ICC color management, is a double edged sword. It's trying to help the user, but it ends up making decisions that don't make any sense to me. The reality is we want the program material to change our monitor 3D LUT to look correct for the material, not the other way around. That's not how 3D LUT based monitor grading works, anyway. You select the space / TF to match what the source is or what you want your final output to be for the color grade.

How do you want player to display your footage to a given display profile if you ask it not to touch your footage?
This only works when you grade to a standard which your monitor is set to. Then it's 1:1 aa in case of grading room. In real world outside of grading room this is not always the case or actually quite often not the case.

3D LUT is a dream atm. as this capability is only available on high-end displays (and even this is not problems free). This is why you move conversion to your operating system through use GPU.