Final Explanation of Gamma and Color Shift Problems

You export one file with 1-4-1 tag. You can copy exiting file and just change tag with Mogurenko tool. We just change tag- copy way is even "more robust"
You can also do 3rd file with 1-2-1+ gamma.

You export one file with 1-4-1 tag. You can copy exiting file and just change tag with Mogurenko tool. We just change tag- copy way is even "more robust"

OK gotcha.
It's actually easier to change the tags on the delivery page rather than applying the NCLC changes within AMCDX Video Patcher.

Project settings :


Delivery settings :


Result on YouTube:

Result in Resolve :

Similar conclusion.

You can also do 3rd file with 1-2-1+ gamma.

What does "1-2-1 + gamma" mean exactly ?

It means unspecified gamma in NCLC tags so then color sync looks at gamma tag if present and reads value from there. It’s MOV only.

Now take actual 2.2 encoded file tagged 1-4-1 send to YT and import converted/downloaded file back to Resolve. It should still look good and have 1-1-1 tag. If it doesn’t then whatever YT is doing is crap.

@Andrew: If you set all at Rec709 (Scene), there's no matching calibration on a monitor since it's a gamma at 1,96, right?

EDIT: Ok that's because you said earlier:

To my knowledge encoding gamma for 2.4 setting in resolve is 1.96 and not 2.4.

That makes no sense no to me. Maybe someone at BMD would be able to confirm or not.

Well, it's all 1.96 based I assume.

For me 'Rec.709' graded file is expected to always have 1.96 encoding. It's later at display stage decided at what gamma will be image finally shown (2,4 or 2,2 etc.), but math expects to start from 1.96 in my understanding.

2.2 gamma preset in Resolve is actually 2.2 curve, so it's different.
sRGB is also own curve as well as 2.6, HDR etc.

That makes no sense no to me. Maybe someone at BMD would be able to confirm or not.

I would love that.

To my knowledge encoding gamma for 2.4 setting in resolve is 1.96 and not 2.4.

That makes no sense no to me. Maybe someone at BMD would be able to confirm or not.

Very easy to prove. Export file with gamma set to Rec.709 and then with 2.4. Then change tag for 2.4 to 1-1-1 and it will look 100% same as Rec.709 one which means actual video data is the same
Now change 1-1-1 tag to 1-2-1 + 1.96 gamma and it will look 100% same as 1-1-1 meaning it's 1.96 behind 1-1-1 tag

It makes sense as BT.1886 spec was introduced for display stage. Original Rec.709 spec did not change, so in order to use BT.1886 you should use original encoding curve which is about 1.96 based.
Well- I also wish someone with actual knowledge explained it, but this is now starting all to make more sense than before.

As I said (quote from BT.1886 spec):

j) that Recommendation ITU-R BT.709, provides specifications for the opto-electronic transfer characteristics at the source, and a common electro-optical transfer function should be employed to display signals mastered to this format,
...
While the image capture process of Recommendation ITU-R BT.709 had an optical to electrical transfer function, there has never been an EOTF documented. This was due in part to the fact that display devices until recently were all CRT devices which had somewhat consistent characteristics device to device.

This Recommendation does NOT change any signal parameters defined in Recommendation ITU-R BT.709; legacy installations are not impacted.

So BT.1886 is new EOTF and should be used with original OETF form Rec.709 spec.
This is how I understand it. This means there is no such a thing like 2.4 encoding curve. I don't see Resolve 2.4 gamma preset applying actual 2.4 curve. It applies 1.96 curve as per Rec.709 original spec.

@Andrew: If you set all at Rec709 (Scene), there's no matching calibration on a monitor since it's a gamma at 1,96, right?
EDIT: Ok that's because you said earlier:

To my knowledge encoding gamma for 2.4 setting in resolve is 1.96 and not 2.4.

That makes no sense no to me. Maybe someone at BMD would be able to confirm or not.

EOTF of the display is not an inverse of the encoding OETF because that would produce end-to-end gamma of 1.0 which is not suitable for dim surround environment. Think of end-to-end gamma as a rudimentary picture rendering. It needs to be above 1.0 to make the image look pleasing and not washed out in that environment (same as in cinema, where end-to-end gamma is even higher due to dark surround). Since CRT-s had a fixed gamma function (property of hardware), encoding was modified to produce that "picture rendering" where end-to-end gamma is ~1.2. To do that, picture encoding uses a transfer function specified in the Rec.709 spec that is approximated by gamma correction for ~1.96. It does not actually apply 1.96 anywhere, so referencing it as such is technically wrong. It has a linear toe and for the rest of the curve applies gamma of 0.45 with an offset.

Encoding with power function OUT = pow(1/2.4, IN) is wrong for rec709 for reasons above and as such, anything that implies that actual encoding function has anything to do with 2.4 is wrong too.

This thread consistently confuses image encoding with display calibration curves. Keep the two strictly separate and things get clearer.

Wiki says the same:

The display EOTF of HDTV (sometimes referred as the "display gamma"), is not the inverse of the camera OETF.[19] The EOTF is not specified in Rec. 709. It is discussed in EBU Tech 3320 and specified in ITU-R BT.1886 as an equivalent gamma of 2.4, that is deviating from it in black region depending on how deep the black is.[20][21] This is a higher gamma than the approximately gamma 2.0 of Rec. 709 OETF. The resulting end-to-end system gamma (OOTF) of HD television system is about 1.2 and it has been deliberately designed to provide compensation for the dim surround effect.[19]

Hence Apple's so called 'boost'=1.22 for BT.1886 ref mode. This expects 1.96 encoded image which will be displayed at around 2.4 final gamma. I assume similar math is performed in TVs with BT.1886 setting.

It means unspecified gamma in NCLC tags so then color sync looks at gamma tag if present and reads value from there. It’s MOV only.

OK so just another test with Rec.709 tagged 1-2-1 (unspecified). I didn't get the "+gamma" thing...

On YouTube :

Resolve comparison :

Now take actual 2.2 encoded file tagged 1-4-1 send to YT and import converted/downloaded file back to Resolve. It should still look good and have 1-1-1 tag. If it doesn’t then whatever YT is doing is crap.

I have already done this earlier today in my tests, in the long post where I explain my process.

You can check the comparison again here :

Ok i'm trying to resume, please correct me if I'm wrong somewhere:

- Rec.709 Gamma encoding is always 1,96 whatever.

- Rec.709 Gamma decoding may be either 2,2 or 2,4 on calibrated monitors (or 1,96 with Rec709-A on OSX preview / Quicktime player which is another story - besides their Color Sync thing which makes the gamma boost). That's what we set in DaVinci Color Management.

- Rec.709 tag 1-1-1 is expected by Youtube/Vimeo to decode properly the image.

- Files exported in Rec.709 gamma 2,2 are tagged 1-4-1 by DaVinci which require an overwriting tag to get 1-1-1 for Youtube/Vimeo.

- Computers (and smartphones?) displays use sRGB ICC profile which has a gamma decoding value at 2,2. *

- Grading with a Rec.709 Gamma 2,4 Color Management in DaVinci and with a calibrated monitor requires a CST conversion (and not just a correct tagging) to display properly in Youtube/Vimeo run on a sRGB GUI environment.

EDIT

* ICC default profile on Mac is "Color LCD" which may use a gamma 2,2 curve - the same as their "Display P3" (P3-D65).

Yes, most of it.
All those preview issues on Mac are still a problem.

I think issue is that non-reference screen profiles treat 1-1-1 files as 1.96 gamma, which is wrong. We need this correction, which is present only in ref mode. Until this is fixed we are forced to use eg. Rec.709-A for Mac screens.

Yes, most of it.
All those preview issues on Mac are still a problem.

I think issue is that non-reference screen profiles treat 1-1-1 files as 1.96 gamma, which is wrong. We need this correction, which is present only in ref mode. Until this is fixed we are forced to use eg. Rec.709-A for Mac screens.

For Mac screens in general or for Quicktime player / OSX Player only? AFAIK, web browsers take by default the color profile selected in the O.S. We can force Chrome to sRGB but 99,99% of people won't do it (I'm in the 0,01%).

Whatever uses OSX managed preview, so most of it (unless as you said you force something).

Andrew and Bastian, thank you for your posts. I ran new tests today and was able to replicate the behavior shown in your tests — YouTube is finally reading and encoding based on some source tags. That is surprising. Despite running the exact same tests just weeks ago, it does appear that YouTube has recently changed to actually adjusting the image when encoding to account for the NCLC tags for 2.2 gamma (1-4-1) and for sRGB encoding gamma (1-13-1). It treats 1-1-1 NCLC and 1-2-1 NCLC the same as before, along with any other that has unspecified tags.

It finally appears to work as it should have all along. In cases where we have control over the tags, the simplest thing is probably to follow Daniele Siragusano's original advice to both encode and tag for sRGB since that will appear as correct as possible on both PC and Apple devices (as long as the tags will be maintained through to YouTube upload, which is a risk in cases where clients will be compressing before upload). The step missing in Resolve which Baselight has built in is an adjustment to account for the viewing condition difference between the grading reference lighting environment and the usually much brighter lighting environment in which people watch YouTube, but that can be approximated.

YouTube has recently changed to actually adjusting the image when encoding to account for the NCLC tags for 2.2 gamma (1-2-1) and for sRGB encoding gamma (1-13-1).

I guess you mean gamma 2.2 (1-4-1), right?

Good to know that you came to the same conclusion.

I guess you mean gamma 2.2 (1-4-1), right?

Good catch of my typo there. Thank you. Yes, 1-4-1 NCLC tags. I've edited my post to correct that.

Andrew and Bastian, thank you for your posts. I ran new tests today and was able to replicate the behavior shown in your tests — YouTube is finally reading and encoding based on some source tags. That is surprising. Despite running the exact same tests just weeks ago, it does appear that YouTube has recently changed to actually adjusting the image when encoding to account for the NCLC tags for 2.2 gamma (1-4-1) and for sRGB encoding gamma (1-13-1). It treats 1-1-1 NCLC and 1-2-1 NCLC the same as before, along with any other that has unspecified tags.

It finally appears to work as it should have all along. In cases where we have control over the tags, the simplest thing is probably to follow Daniele Siragusano's original advice to both encode and tag for sRGB since that will appear as correct as possible on both PC and Apple devices (as long as the tags will be maintained through to YouTube upload, which is a risk in cases where clients will be compressing before upload). The step missing in Resolve which Baselight has built in is an adjustment to account for the viewing condition difference between the grading reference lighting environment and the usually much brighter lighting environment in which people watch YouTube, but that can be approximated.

It would be cool if YT could actually pass sRGB tagged source as this works quite well on PC and Mac. But I assume it will convert video and change tag to 1-1-1?

Hmmm... I just exported sRGB video and downloaded it back. Tag is changed, but actual data is not converted to anything- it's the same video. Re-tagged downloaded file back to sRGB and it 100% matches starting one.

If you see a difference then this is actually nothing good, but means that only tag changed not actual video. If YT performed correct conversion then new file with 1-1-1 tag should match your source (well - at least by eye).

I'm getting back not merely different tags, but actually different image data from the uploaded source, confirmed by external scopes without any management or transform of the file involved. And I also checked to make sure it wasn't merely a levels misinterpretation.

How are you running your test?

I ran today's tests in the middle of a busy day. I need to set aside a day to run them again, along with additional tests and document it all properly.

Maybe it's not global change yet.
I just upload file to YT (free account).
Is your "converted" file looking the same in QT X player against source?

It is unclear what YouTube is doing to the image. So far I am just shocked that it changed the image data at all, since that had never happened before. In the past, when I uploaded multiple files of the same image to Youtube and only changed the variable of NCLC metadata, the image displayed on color managed browsers on macOS/iOS was always identical between all the files — my conclusion was that YouTube ignored source tags. Yesterday, when I ran the exact same test, the image displayed was different for certain NCLC tags. That's entirely new behavior. Now I need to spend time conducting more specific tests to determine what transform it is actually applying to files with those tags.

I had same experience.
For me it did not convert now either, so it's even more confusing

So I just poked at those files that I got back out of YouTube — YouTube truly did the transform on top of the tag. For the clip with a 1-4-1 tag the actual image data was transformed in the encoding from gamma 2.2 to Rec.709 gamma, and for the clip with a 1-13-1 tag the actual image data was transformed in the encoding from sRGB encoding gamma to Rec.709 gamma.

Well then it's how it should be- normalised to Rec.709.
It just didn't do it for me for sRGB file. Go figure.

This recent turn of events you two are reporting is making me wonder whether I accidentally switched places with one of the other Steve's in a parallel universe...

With the James Webb telescope in action, parallel universes are all over YT

3rd - use BT.1886 reference mode (when possible) during grade and when watching YT.

Can you elaborate ?
Correct me if I'm wrong :
You set BT.1886 reference mode for your Apple Display
Project Settings ➧ Color Management ➧ color Science ➧ Color managed
Project Settings ➧ Color Management ➧ output color space ➧ rec709Gamma2.4
Davinci Preferences ➧ Sytem ➧ General ➧ Use Mac display profiles for viewer ➧ Checked
Grade looking your viewer or your video cleanFeed .. on your Apple Display
Deliver with same color space and with witch tag 1-1-1 or 1-2-1 ?
Upload to Youtube
Watch it on YouTube on the Apple Display

I'll give a try
thanks

This should give same preview, but I'm not sure about it as Resolve is still behaving strangely to me.

When I've tested the BT.1886 "reference mode" in the Resolve GUI (even the "clean feed", it's the same image as the rest of the Resolve GUI viewers) side by side against the Decklink output to my FSI reference display, the only output color space setting where the image matched was Rec.709-A. This makes sense considering that Apple has made reference mode for it's own color managed apps, such as FCP, and Rec.709-A in Resolve is the one output color space setting for the purpose of matching the GUI in those apps, whether the Mac display is set to BT.1886 "reference mode" or not.

Thanks for the feed back ...

When I've tested the BT.1886 "reference mode" in the Resolve GUI (even the "clean feed", it's the same image as the rest of the Resolve GUI viewers) side by side against the Decklink output to my FSI reference display, the only output color space setting where the image matched was Rec.709-A. This makes sense considering that Apple has made reference mode for it's own color managed apps, such as FCP, and Rec.709-A in Resolve is the one output color space setting for the purpose of matching the GUI in those apps, whether the Mac display is set to BT.1886 "reference mode" or not.

Resolve preview still doesn't make sense for me.
Rec.709-A gives "final" look on OSX system as it's "pre-darkened".
It gives the same look as native Resolve 2.4 exported file (1-2-1+2.4 gamma) which is decoded as 2.4 gamma. Rec.709-A uses 1.60 encoding gamma (so 1.96/1.22), so when it's decoded with 1.96 gamma (which happens in OSX for 1-1-1) tag gives similar to 2.4 gamma preview.

Rec.709-A with ref mode, which adds 1.22 correction for me should be wrong against ref screen (as then it's "double 1.22 corrected").
Standard Rec.709 (scene) exported file (1.96 encoded, 1-1-1, tagged) watched with BT.1886 ref mode should be aligned with ref screen.

ColorSync, ICC profiles and all other OS level color management are to some extent a black box to me since I do not know how to isolate and control all the variables at every step in the chain.

All I can say for certain is:

- My FSI reference display (and the signal chain to it) displays accurate BT.1886
- With reference mode turned on in my 16" MacBook Pro, setting Resolve to "use mac display profiles" in an unmanaged YRGB project with the output color space set to Rec.709-A the GUI viewer image is a visual match to both the image on my FSI reference display and the same frame loaded in the FCP GUI viewer. And this is the only output color space setting which yields a match.

GUI viewer comparison.jpg (687.29 KiB) Viewed 191673 times

- If "use Mac display profiles" is turned off, then the Resolve GUI viewer image on the MacBook Pro set to BT.1886 reference mode does not match the reference image on the FSI reference display.

this is a good news ...
Can you try the video Clean feed on the MacBook Pro Display (you'll need an external monitor for Resolve GUI) ?

this is a good news ...
Can you try the video Clean feed on the MacBook Pro Display (you'll need an external monitor for Resolve GUI) ?

Clean Feed is identical to the Resolve GUI viewer image.

this is a good news ...
Can you try the video Clean feed on the MacBook Pro Display (you'll need an external monitor for Resolve GUI) ?

For me it's bad news
Resolve GUI preview should work fine for Rec.709 (scene or 2.4 preset or any time when encoding gamma is 1.96). Rec.709-A is some made up gamma curve.

this is a good news ...
Can you try the video Clean feed on the MacBook Pro Display (you'll need an external monitor for Resolve GUI) ?

For me it's bad news
Resolve GUI preview should work fine for Rec.709 (scene or 2.4 preset or any time when encoding gamma is 1.96). Rec.709-A is some made up gamma curve.

I understand your point of view.

Resolve GUI preview should work fine for Rec.709 (scene or 2.4 preset or any time when encoding gamma is 1.96). Rec.709-A is some made up gamma curve.

Yup. Totally made up. But that is on Apple doing its own wonky thing, not on BMD. Rec.709-A in Resolve is merely doing for its GUI display exactly what Apple does for the GUI display of Rec.709 sources in Apple's own video apps.

Yes, but with ref modes it should work properly with standard encoding gamma of 1.96.
If ref mode applies 1.22 correction to get 2.4 decoding gamma then why 1.96 based project in Resolve doesn't give correct preview? (maybe because ref mode works only with files where it sees 1-1-1 tag?)
I understand that no-ref mode which simply applies 1.96 decoding gamma gives bad preview. This is as expected and a reason for existence of Rec.709-A.
Ref mode should work without Rec.709-A (assuming your encoding gamma was 1.96).

I'm not saying we have to encode the actual image data as Rec.709-A. To get the Resolve GUI image on a Mac display set to BT.1886 reference mode to display Rec.709 encoded images in BT.1886, ColorSync just needs to be fed the same input as it would get from FCP or any other Apple video app. In Resolve, that means working in an unmanaged project with the output color space set to Rec.709-A. That output color space setting doesn't change the image data on the timeline, it only controls the GUI viewer image and the output NCLC tags.
And yup, that is totally dumb and counterintuitive. But, if we want to use Apple's displays, we have to work on top of Apple's legacy decisions about how to display Rec.709 encoded images.

If you've got a Mac display with reference mode, and an external BT.1886 reference display, it is simple to verify. Just compare the same Rec.709 encoded 1-1-1 NCLC tagged image between FCP and Resolve in both apps GUI viewers and the image on the reference display out of both apps.

And to restate it, since the question as asked earlier in the thread, the "clean feed" output option in Resolve follows the same OS color management as the viewers on the Media, Edit, Fairlight, Color and Deliver pages whenever the "use Mac output display profiles" option is engaged in preferences. The Fusion page GUI and reference output is, for better or worse, a whole other can of worms.

(*the output color space setting does also impact Dolby Vision workflows, but that isn't relevant to working in SDR).

Have you compared QTX output (not Resolve GUI) for 1-1-1 tagged file in ref mode against ref screen?

Have you compared QTX output (not Resolve GUI) for 1-1-1 tagged file in ref mode against ref screen?

QTX is identical to the FCP GUI viewers. All of Apple's video apps GUI viewers work the same with 1-1-1 tagged media, as will any application that works with ColorSync, which includes nearly all browsers and iOS/iPadOS apps.

I don't care about FCPX GUI preview
I care if ref mode gives correct output QT X (against reference screen) in ref mode for properly graded/tagged file.

You grade file to Rec.709 preset on FSI screen, then export and watch it in QT X. We assume file is 1-1-1 tagged. Does BT.1886 ref mode in QT X (we don't care here about Resolve at all) match FSI preview?

Yes, it does.

The caveat if Quicktime Player *on a Mac display set to BT.1886 reference mode* is being used for remote client reviews is that to perceive the same image as was seen in the color suite, it will need to be viewed in standard dim surround D65 reference lighting.

Ok, at leat this makes sense.
In the same time it doesn't make sense why Resolve preview can't be accurate for standard Rec.709 project.

Well- you can always copy BT.1886 mode and raise brightness to desired value, opposite to ref 100nits. I assume this somehow can compensate for brighter than reference room.

In the same time it doesn't make sense why Resolve preview can't be accurate for standard Rec.709 project.

There's no way for Resolve to know what mode the Mac display is in. The only option BMD has is to pass transfer function and gamut metadata (from the output color space setting) on to ColorSync. Or, to not send any metadata at all, which is what toggling off the preference for "use Mac display profiles" will do, but that won't make for an accurate image in the GUI unless the media is encoded identical to the unmanaged state of the display.

Since Resolve version 15 (or was it 16?), when the output color space (used to be just the timeline color space) is set to Rec.709 gamma 2.4, Resolve has been applying the 1-2-1 NCLC tag with additional metadata to identify the gamma as 2.4. If BMD switched back to what it did before that, sending the 1-1-1 NCLC for the Rec.709 gamma 2.4 output setting, you'd get what you're asking for. However, there's a cost to that too in terms of what will be displayed when the Mac isn't set to reference mode.

Ultimately, as has been said many times better by others, the problem here is the shift from a world where it worked fine that the intended display gamma was only implicit, to one in which it really needs to be explicit. We're still caught in the mess in the middle of that.

Well- it should work properly with ref modes at least. Non-ref mode is broken anyway and it's not Resolve fault.

I'm 99% sure you can read current display settings (ref/non-ref mode etc.) and do a lot with it. You should be even able to totally separate yourself from OSX management and with ref modes have same behaviour like with reference screen over SDI. All what we needed is ability to put screens into correct gamut/gamma mode (like with ref screens) and now it's possible.

I don't think Resolve is working properly with ref modes enabled atm. based on your reports.

Well- it should work properly with ref modes at least. Non-ref mode is broken anyway and it's not Resolve fault.

I'm 99% sure you can read current display settings (ref/non-ref mode etc.) and do a lot with it. You should be even able to totally separate yourself from OSX management and with ref modes have same behaviour like with reference screen over SDI. All what we needed is ability to put screens into correct gamut/gamma mode (like with ref screens) and now it's possible.

I agree
I have no time now, but it is something l'll surely test
I have a MacBook Pro without Monitoring or I got a Mac Studio with monitoring and no Apple display ....

As far as I can see, "reference mode" on the Mac doesn't bypass ColorSync. It is not as if the display will show an unmanaged signal as BT.1886 such that an app can ignore ColorSync and yield the right result on screen. If that were the case, Rec.709 source media played in VLC would appear correct, yet it doesn't.

But what do I know. I don't have the skills to dig under the hood. I'm just putting images in and viewing what comes out the other side on the Mac display vs the Decklink connected FSI reference monitor to draw conclusions.

No, it works with color sync as far as I can tell, but with developer tools you have access to another level of possibilities.
I've done tests with developers of an open source tool where we had Mac GUI displayed normally, but video preview in its own window through a different mode (gamma etc.). We had even preview with no gamma at all as a test. It's a strange feeling to have 2 independent parts of the screen in different modes.
I'm not a developer, but I think you can do a lot if you have skills.