Rec.709-A Gamma Shift in Exports in DaVinci Resolve 18.5b4

I work on a Macbook Pro and have usually used my timeline and output color space settings in Rec.709-A in order to prevent gamma shift in my exports, which used to work pretty well before.

But now with the new 18.5 Beta it seems I'm getting gamma shift with these export settings that I didn't used to get.

Is anyone else experiencing this / is there a better or new approach now to avoid gamma shift on Mac exports?

Here are my full color space and export settings I'm using:

Color science: Davinci YRGB
Timeline Color Space: Rec-709-A
Output Color Space: Rec-709-A

Export settings in screenshot attached.

Try setting the timeline color space to do wide gamut or p3 d65 depending on the color calibration of your monitor.

Try setting the timeline color space to do wide gamut or p3 d65 depending on the color calibration of your monitor.

What is the logic behind this suggestion? What has timeline colorspace got to do with monitor calibration?

How are you checking for the gamma shift? Are you importing the rendered clips into Resolve to check against the original or using an external media player?

I’d guess external player as this is why Rec709-A exists in the firstplace, to cure the gamma shifts in some external players/services.

It makes perfect sense if you understand how the color science is implemented. The timeline color space is used to mate the display characteristics to the timeline to take full advantage of its characteristics. The output color space is defined as rec709a and resolve maps what you were seeing on your monitor to the output color space. This is exactly what happens coming in. The input video’s colors are mapped from whatever color space they were shot in, to display correctly on your monitor.

This flow is the essence of resolve color management. The manual describes this quite well.

The timeline working colourspace does not have to match the display colourspace.
It's the Output Colourspace that is fed to the Resolve interface viewers and the Blackmagic Desktop Video devices, not the timeline working colourspace.

This flow is the essence of resolve color management. The manual describes this quite well.

I suggest reading the manual again, read what Peter wrote above.

It makes perfect sense if you understand how the color science is implemented. The timeline color space is used to mate the display characteristics to the timeline to take full advantage of its characteristics. The output color space is defined as rec709a and resolve maps what you were seeing on your monitor to the output color space. This is exactly what happens coming in. The input video’s colors are mapped from whatever color space they were shot in, to display correctly on your monitor.

This flow is the essence of resolve color management. The manual describes this quite well.

The original post does not mention any color management (ColorScience ➧ Davinci YRGB).
May be you have read it too fast ?
FYI Output color Space menu in this case is only for Tagging.
On Mac it triggers ColorSync (color display management)

I’d guess external player as this is why Rec709-A exists in the firstplace, to cure the gamma shifts in some external players/services.

Yes I am opening it with Quicktime and comparing side by side, where there's an obvious difference.

I do need to learn more about monitor calibration, however I so far have only used my own Macbook Pro's screen for monitoring. I thought Rec709-A was made for Apple screens and as long as I was coloring in that colorspace it would match the output pretty closely, if not exactly.

I don't understand why the QuickTime Player wouldn't properly read the color space tags and do the right thing on the same Mac. I thought the Rec709-A color space (1:1:1) was for other players that assumed a color space / gamma.

I’d guess external player as this is why Rec709-A exists in the firstplace, to cure the gamma shifts in some external players/services.

Yes I am opening it with Quicktime and comparing side by side, where there's an obvious difference.

I do need to learn more about monitor calibration, however I so far have only used my own Macbook Pro's screen for monitoring. I thought Rec709-A was made for Apple screens and as long as I was coloring in that colorspace it would match the output pretty closely, if not exactly.

How are you comparing side by side? Which apps for each side by side display?

My preferred settings are to use rec709 scene for Output colourspace and then on the Deliver Page rec709 for colourspace with gamma set to 2.4. It is a really close match to the Resolve viewers when comparing to both Quicktime Player and VLC. It will never be perfect simply because the Resolve viewers are not colour managed in the same way that external apps are managed. I also do not use the "Use mac display profile for viewers" option in System settings as that will not match my external Flanders calibrated monitor as well as leaving it off. I get a perfect match when re-importing the rendered clip into Resolve.

Do you have Use Mac Displays checked in preferences?

I’d guess external player as this is why Rec709-A exists in the firstplace, to cure the gamma shifts in some external players/services.

Yes I am opening it with Quicktime and comparing side by side, where there's an obvious difference.

I do need to learn more about monitor calibration, however I so far have only used my own Macbook Pro's screen for monitoring. I thought Rec709-A was made for Apple screens and as long as I was coloring in that colorspace it would match the output pretty closely, if not exactly.

How are you comparing side by side? Which apps for each side by side display?

My preferred settings are to use rec709 scene for Output colourspace and then on the Deliver Page rec709 for colourspace with gamma set to 2.4. It is a really close match to the Resolve viewers when comparing to both Quicktime Player and VLC. It will never be perfect simply because the Resolve viewers are not colour managed in the same way that external apps are managed. I also do not use the "Use mac display profile for viewers" option in System settings as that will not match my external Flanders calibrated monitor as well as leaving it off. I get a perfect match when re-importing the rendered clip into Resolve.

I am opening the file via Quicktime and looking at it next to the video in Resolve which I have been monitoring for color.

Are you also using rec709 scene for timeline color space in the settings you described?

Do you have Use Mac Displays checked in preferences?

I do not have it checked. Not sure if I did before I upgraded to 18.5 beta and it reset after upgrading? Could this be what would make the rec 709-A method work?

Ok, I just did a test and I think I have a possible reason for why this Rec.709-A is not working correctly in 18.5

I'm on an Apple M1 Max laptop.

"Use Mac display color profiles" IS checked.

I tested my theory using Resolve 18.1.4 as a previous version and both 18.5b4 and the new non beta 18.5


TLDR: In 18.1.4 when I set Timeline and Output to Rec.709-A the viewer shifts to show the change. This shift is identical to how exports from 18.5 look when -A is set as output. The problem is the viewer is not shifting to show Rec.709-A in 18.5 so I am grading my footage based on the look of Rec.709 (scene) and when I export it I am seeing the actual -A curve and it looks shifted.

Basically when I switch from Scene to -A in 18.5 my viewer or clean feed do not change. In 18.1 there is a significant shift when I switch from Scene to -A

Rec709-A is not a different curve, it changes only metadata. Curve is (or is supposed to be) the same as Rec709 Scene. So something in how the color tags are handled in and/or outside Resolve has changed.

I find the new (18.5) ability to have a separate RCM setup and output color space for each timeline tricks me all the time, lol. For example, I setup my timeline RCM output to Rec709 gamma 2.4 (independent of the project's RCM settings) and then forget to explicitly set the tagging on the delivery page to whatever I had set for the timeline. So on the delivery page it will be set to 'Project Settings' which is not the same as those set for my timeline (this is a confusing UI/UX issue, btw). I need to be very careful when using custom timeline RCM settings.

I wish the delivery page would default to the timeline output color tags rather than taking them from the project settings.

I ran into this glitch when I was trying to reproduce the OP's issue on my MacBook. At first I thought I replicated the issue until I double-checked the tagging... Once I got all my settings correct, I found that the QuickTime player created an identical image to the one displayed in Resolve (my Resolve is setup to use Mac color profiles in its viewer and so both QuickTime and Resolve correctly adapt to either Rec709 gamma 2.4 or Rec709-A).

I typically setup my timeline color space to DWG intermediate and the output to either Rec709 gamma 2.4 or Rec709-A.

Rec709-A is not a different curve, it changes only metadata. Curve is (or is supposed to be) the same as Rec709 Scene. So something in how the color tags are handled in and/or outside Resolve has changed.

Yeah, I'll admit I don't fully wrap my head around all of this.

I just know that our team had a working setup in 18.1.4 where using 709-A made a significant change to the look of our viewer that allowed our grades to be consistent on export.

in 18.1.4 any changes I make to Timeline and output color settings reflect in the viewer (and scopes) - it changes significantly (which would lead to us grading differently - thus changing the output - which then in QuickTime looks the same.

in 18.5 I can try all sorts of Timeline/Output color settings in Project Settings panel but my viewer does not change. Maybe I need to reset my preferences or something.

but the "tell" to me is that when I switch 18.1.4 to Rec.709-A the viewer changes to look exactly like how the files I've exported from 18.5 look in QuickTime (which is shifted). So if the 18.5 viewer had shown the shift, my grade would have been different, and QuickTime would match.

Also, in this scenario Quicktime and Vimeo are both showing the shift, not just QuickTime.

Hey, did you guys found some solution? I have same problem since 18.5.
Just to add, even if i export video that is similar in Resolve, VLC and even in Quicktime, it is different when i open it in Chrome browser, or upload it to Frame.io

frustrating

HI, I´ve got the solution. This changed in Davinci 18.5. You have to set up everything like you used to, but, before exporting you must go to the timeline and right click - settings and change the color output there to REC709A. You will notice your client monitor (via ultra studio) changes back to a darker gamma. Your export will be perfect again. I´ve struggled with this problem for a few days until I´ve found out this solution.

Hope this work for you too.

Gabriel

Screenshot 2023-10-10 at 08.47.03.png (112.94 KiB) Viewed 5866 times

Screenshot 2023-10-10 at 08.46.36.png (624.09 KiB) Viewed 5866 times

HI, I´ve got the solution. This changed in Davinci 18.5. You have to set up everything like you used to, but, before exporting you must go to the timeline and right click - settings and change the color output there to REC709A. You will notice your client monitor (via ultra studio) changes back to a darker gamma. Your export will be perfect again. I´ve struggled with this problem for a few days until I´ve found out this solution.

Hope this work for you too.

Gabriel

You confirm changing the Output Color Space (Tag) from Rec709(Scene) to Rec709A change your monitoring ?
Are you monitoring via deckling/utltrastudio or the videoCleanFeed ?
Or you on Mac or PC ?
Thanks

HI, I´ve got the solution. This changed in Davinci 18.5. You have to set up everything like you used to, but, before exporting you must go to the timeline and right click - settings and change the color output there to REC709A. You will notice your client monitor (via ultra studio) changes back to a darker gamma. Your export will be perfect again. I´ve struggled with this problem for a few days until I´ve found out this solution.

Hope this work for you too.

Gabriel

I saw this hours ago and wrote it off as not possibly the fix. It's 100% the fix.

I use a flavor the usual 709-A transform we all do, hundred and hundreds of times, every day, since it came out. Timeline CST node, 2.4 > 709-A, neutralizes the shift in ColorSync/HTML5 on render. Great. Except the last few days I've noticed it no longer truly cancels out, and the web upload remains darker than it should.

BUT.... Took Gabriel's advice, then reimported both tests (my usual way and his suggestion), and uploaded both to Frame, and sure enough, Changing the output to 709-A via either the timeline settings or project settings, instead of via CST node, actually neutralizes the gamma shift correctly. FWIW, I also tagged 709-A on export here.

Really don't love taking hours to scour forums only to find out that a trusted tool for online color accuracy just... doesn't work all of a sudden? Am I missing something? I've already reproduced it. What would cause this?

Wish I saw this earlier. I have not had this issue for a long time but then when an important client project comes around it happened and I couldn't resolve it. Should have checked the export timeline output too as the rest were all Rec709-A.

I've just hit this wall myself. Unbelievably frustrating to have it sorted out and working (as best as currently possible) only to have things change with no notice.

Wish I saw this earlier. I have not had this issue for a long time but then when an important client project comes around it happened and I couldn't resolve it. Should have checked the export timeline output too as the rest were all Rec709-A.

I've just hit this wall myself. Unbelievably frustrating to have it sorted out and working (as best as currently possible) only to have things change with no notice.

We're not crazy!

one big caveat for the next people seeing this: The whole "do it from the project or timeline settings" new advice here is just for RCM. if you color-manage via nodes, it works as always.

What's going on here?!

Is this solution still the way in 18.6.5?
If so, isn't this crucial and should be made clearly known to users?

This worked for me now on an export that was giving me issues, anyone know what's causing this to even happen in the first place? automatic should work fine

This worked for me now on an export that was giving me issues

Which Resolve version?