Final Explanation of Gamma and Color Shift Problems

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 12:51 pm

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.
Offline
User avatar

Bastien

  • Posts: 91
  • Joined: Sat Apr 14, 2018 10:28 am
  • Location: France
  • Real Name: Bastien CHILLOUX

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 1:07 pm

Andrew Kolakowski wrote: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 :
Image

Delivery settings :
Image

Result on YouTube:


Result in Resolve :


Similar conclusion.

Andrew Kolakowski wrote:You can also do 3rd file with 1-2-1+ gamma.
What does "1-2-1 + gamma" mean exactly ?
Last edited by Bastien on Mon Dec 04, 2023 3:43 pm, edited 2 times in total.
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 2:55 pm

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.
Offline

Lucius Snow

  • Posts: 638
  • Joined: Sun Nov 24, 2013 1:19 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 3:02 pm

@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.
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 3:11 pm

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.
Offline
User avatar

Olivier MATHIEU

  • Posts: 856
  • Joined: Thu Aug 04, 2016 1:55 pm
  • Location: Paris/Grenoble, FRANCE

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 3:13 pm

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

I would love that.
Resolve Studio 18.6.x & Fusion Studio 18.6.x | MacOS 13.6.x | GUI : 3840 x 2160 | Ntw : 10Gb/s
MacbookPro M2 Max
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 3:15 pm

Lucius Snow wrote:
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.
Offline

Hendrik Proosa

  • Posts: 3003
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 3:32 pm

Lucius Snow wrote:@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.
I do stuff.
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 3:47 pm

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.
Offline
User avatar

Bastien

  • Posts: 91
  • Joined: Sat Apr 14, 2018 10:28 am
  • Location: France
  • Real Name: Bastien CHILLOUX

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 4:01 pm

Andrew Kolakowski wrote: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 :


Andrew Kolakowski wrote: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 :
Offline

Lucius Snow

  • Posts: 638
  • Joined: Sun Nov 24, 2013 1:19 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 4:06 pm

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).
Last edited by Lucius Snow on Mon Dec 04, 2023 4:57 pm, edited 3 times in total.
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 4:33 pm

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.
Offline

Lucius Snow

  • Posts: 638
  • Joined: Sun Nov 24, 2013 1:19 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 5:02 pm

Andrew Kolakowski wrote: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%).
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 5:28 pm

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

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 10:18 pm

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.
Last edited by Jamie LeJeune on Mon Dec 04, 2023 10:41 pm, edited 1 time in total.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline
User avatar

Bastien

  • Posts: 91
  • Joined: Sat Apr 14, 2018 10:28 am
  • Location: France
  • Real Name: Bastien CHILLOUX

Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 10:30 pm

Jamie LeJeune wrote: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.
Blackmagic URSA Mini Pro 4.6K G2 • DZOFilm Pictor Zooms • Easyrig Vario 5 Stabil G2
Website : https://bastienchilloux.com
Instagram : https://www.instagram.com/bastienchill.dp/
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 10:42 pm

Bastien wrote: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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 10:55 pm

Jamie LeJeune wrote: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?
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Dec 04, 2023 11:04 pm

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).
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Dec 05, 2023 12:26 am

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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Dec 05, 2023 10:15 am

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?
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Dec 05, 2023 7:38 pm

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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Dec 05, 2023 8:13 pm

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

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Dec 05, 2023 9:50 pm

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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Dec 05, 2023 11:05 pm

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.
Offline

Steve Alexander

  • Posts: 4478
  • Joined: Mon Mar 23, 2015 2:15 am

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Dec 06, 2023 2:48 am

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...
Time Traveller
Resolve Studio 18.6.5 | Fusion Studio 18.6.5 | Win 11 Pro (22H2) | i9-7940x, P4000 (536.96, 8GB VRAM), 64GB RAM, M.2 boot, SSD scratch, RAID10 data | (laptop) 16" MacBook Pro M1 MAX, 32 GPU cores, 64 GB RAM, 2 TB SSD, Sonoma 14.3.1
Offline

Uli Plank

  • Posts: 20890
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Dec 06, 2023 2:57 am

With the James Webb telescope in action, parallel universes are all over YT ;-)
Maybe AI can help you. Or make you obsolete.

Studio 18.6.5, MacOS 12.7.3
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline
User avatar

Olivier MATHIEU

  • Posts: 856
  • Joined: Thu Aug 04, 2016 1:55 pm
  • Location: Paris/Grenoble, FRANCE

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Dec 06, 2023 7:23 am

Andrew Kolakowski wrote:
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
Resolve Studio 18.6.x & Fusion Studio 18.6.x | MacOS 13.6.x | GUI : 3840 x 2160 | Ntw : 10Gb/s
MacbookPro M2 Max
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Dec 06, 2023 10:06 am

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

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 07, 2023 3:38 am

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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline
User avatar

Olivier MATHIEU

  • Posts: 856
  • Joined: Thu Aug 04, 2016 1:55 pm
  • Location: Paris/Grenoble, FRANCE

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 07, 2023 7:03 am

Thanks for the feed back ...
Resolve Studio 18.6.x & Fusion Studio 18.6.x | MacOS 13.6.x | GUI : 3840 x 2160 | Ntw : 10Gb/s
MacbookPro M2 Max
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 07, 2023 12:29 pm

Jamie LeJeune wrote: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.
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 07, 2023 8:40 pm

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
GUI viewer comparison.jpg (687.29 KiB) Viewed 2986 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.
Last edited by Jamie LeJeune on Thu Dec 07, 2023 8:52 pm, edited 1 time in total.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline
User avatar

Olivier MATHIEU

  • Posts: 856
  • Joined: Thu Aug 04, 2016 1:55 pm
  • Location: Paris/Grenoble, FRANCE

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 07, 2023 8:52 pm

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) ?
Resolve Studio 18.6.x & Fusion Studio 18.6.x | MacOS 13.6.x | GUI : 3840 x 2160 | Ntw : 10Gb/s
MacbookPro M2 Max
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 07, 2023 8:55 pm

Olivier MATHIEU wrote: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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 07, 2023 9:28 pm

Olivier MATHIEU wrote: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.
Offline
User avatar

Olivier MATHIEU

  • Posts: 856
  • Joined: Thu Aug 04, 2016 1:55 pm
  • Location: Paris/Grenoble, FRANCE

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 07, 2023 10:11 pm

Andrew Kolakowski wrote:
Olivier MATHIEU wrote: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 Studio 18.6.x & Fusion Studio 18.6.x | MacOS 13.6.x | GUI : 3840 x 2160 | Ntw : 10Gb/s
MacbookPro M2 Max
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 08, 2023 3:59 am

Andrew Kolakowski wrote: 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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 08, 2023 12:43 pm

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).
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 08, 2023 8:39 pm

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).
Last edited by Jamie LeJeune on Fri Dec 08, 2023 8:53 pm, edited 1 time in total.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 08, 2023 8:53 pm

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

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 08, 2023 8:55 pm

Andrew Kolakowski wrote: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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 08, 2023 8:57 pm

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?
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 08, 2023 10:24 pm

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.
Last edited by Jamie LeJeune on Sat Dec 09, 2023 12:44 am, edited 1 time in total.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 08, 2023 10:27 pm

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.
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 09, 2023 4:10 am

Andrew Kolakowski wrote: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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 09, 2023 9:53 am

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.
Offline
User avatar

Olivier MATHIEU

  • Posts: 856
  • Joined: Thu Aug 04, 2016 1:55 pm
  • Location: Paris/Grenoble, FRANCE

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 09, 2023 9:56 am

Andrew Kolakowski wrote: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 ....
Resolve Studio 18.6.x & Fusion Studio 18.6.x | MacOS 13.6.x | GUI : 3840 x 2160 | Ntw : 10Gb/s
MacbookPro M2 Max
Offline
User avatar

Jamie LeJeune

  • Posts: 2010
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 09, 2023 7:45 pm

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.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 9205
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 09, 2023 8:13 pm

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.
PreviousNext

Return to DaVinci Resolve

Who is online

Users browsing this forum: GlobalHeroes, JJFIII and 148 guests