RCM Gamma bug? - RCM vs RCM2

I've noticed a Gamma Shift between the "Legacy" RCM and the new instance of RCM. All the "DRT" stuff has been disabled, so it's a straight like-for-like comparison between Legacy and new RCM with Timeline and Output set to Rec.709 Gamma 2.4

Legacy RCM

Legacy_RCM.jpg (106.75 KiB) Viewed 2695 times

RCM v2

RCM2.jpg (109.71 KiB) Viewed 2695 times

My understanding to this point has been that the Rec.709 Gamma 2.4 setting uses a straight power 2.4 gamma curve (or 2.2 for Gamma 2.2). Is it no longer the case, or is this a bug in Resolve 17?

Project Archive files linked below:

https://gofile.io/d/Fub3Jl

Can someone from BMD please clarify.

Is this a bug, or has there been a change to the Rec.709 Gamma 2.4/2.2 implementations?

Ok... so after zero responses from anyone else and some further analysis, it appears that as of Version 17, Rec 709 Gamma 2.4 is now functioning as Rec 709 Scene.

It's either a bug in development or a deliberate change.

Either way, Gamma 2.4 in Resolve 17 is no longer the same as Gamma 2.4 from prior versions of Resolve.

User beware.

... it appears that as of Version 17, Rec 709 Gamma 2.4 is now functioning as Rec 709 Scene.
It's either a bug in development or a deliberate change.

This must be considered a bug because rec709 scene must be rec709 curve with linear segment at toe and pure 2.4 gamma curve must not if compatibility with any other software is expected.

Unfortunately there hasn't been a response on this from BMD.

Technically speaking, the timeline should always have been Rec.709 Scene and not a pure Gamma 2.4 power function.

The current situation is very misleading and will confuse people.

I noticed that Beta 6 has made Rec.709 Scene the default timeline gamma, which is great!

However, the issue of Gamma 2.4 out still incorrectly outputting as Rec.709 Scene still remains.

My guess is that someone somewhere decided that using pure gamma curve as encoding curve for rec709 is wrong (and it is), but had a great idea for a “fix” by simply internally overriding 2.4 curve.

Why pure gamma 2.4 corrected encoding is wrong? Because most people think it is correct rec709 encoding curve, but it isn’t. And it isn’t correct view curve either. As a strictly data encoding it is fine, but not for sending to display. Why it is widely used as such, I have never understood, result is that people compensate for it manually during grading, unknowingly fighting the resulting too low end to end gamma.

Technically, wouldn't Power Gamma 2.4 for output be correct when viewed on screens that are configured to BT.1886, as the BT.1886 math on a display "should" apply the appropriate compensations for CRT matching?

With BT.1886, when Lw = 100 and Lb = 0, you get a pure 2.4 power gamma curve.



More to the topic, I'm a bit surprised nobody else has picked up on this fundamental change with Gamma 2.4 outputs as yet.

BT.1886 is display curve, an EOTF. And yes it can be pure 2.4 gamma with these settings. But this doesn’t imply in any way that encoding of data should be also pure gamma 2.4 corrected (raised to 1/2.4 power). Result of this would be end to end gamma of 1.0 which is too low for dim surround environment. BT.1886 expects input data encoded with rec709 encoding curve, the one with linear segment, and display calibrated to BT.1886 produces appropriate end to end gamma for specified view environment.

If my understanding is wrong and end to end gamma of 1.0 is actually desirable for dim surround, I’m all ears for explanation of the ”why”.

Confirm.
In new RCM Gamma 2.4 and Gamma 2.2 have linear segment near black now.
But what is really bad is how it works with sRGB now.
If I set input to sRGB, timeline to, say, LogC, and turn off all the tonemapping things, instead of converting from sRGB to LogC, thats what happening:

At first image converting from sRGB to pure gamma 2.4. And then, to the resulting image, applying another conversion from REC709 to LogC.

Seems like BM decided that their users don't know what is pure gamma and what is linear segment near black in rec709 and sRGB. But if the decision is to remove pure gamma and sRGB encoding curve from new RCM at all - maybe it's a good idea to name it properly instead of confusing people, who expect that gamma 2.4 means gamma 2.4 (pure gamma without linear segment near black)

But of course I prefer gamma 2.4 still be pure gamma 2.4. Probably it should be renamed to Pure Gamma 2.4.

BT.1886 is display curve, an EOTF. And yes it can be pure 2.4 gamma with these settings. But this doesn’t imply in any way that encoding of data should be also pure gamma 2.4 corrected (raised to 1/2.4 power). Result of this would be end to end gamma of 1.0 which is too low for dim surround environment. BT.1886 expects input data encoded with rec709 encoding curve, the one with linear segment, and display calibrated to BT.1886 produces appropriate end to end gamma for specified view environment.

If my understanding is wrong and end to end gamma of 1.0 is actually desirable for dim surround, I’m all ears for explanation of the ”why”.

It depends what the input to your 2.4 gamma display encoding is. If it is your desired display colorimetry, then you absolutely want an end to end gamma of 1.0 so it cancels out. When you have a DRT being used, that is what should be applying the picture rendering, so you should not need additional gamma in the display encoding (inverse EOTF). That “system gamma” is a legacy “video” very simple form of DRT when going from scene to display-referred.

When you say “BT.1886 expects…” that is really only in the simplest form of direct legacy television camera direct to display system, with no grading applied.

I have to say also that I personally am not a fan of defaulting to Rec.709 (scene) as the timeline colour space. If you have “Use Mac display color profiles for viewers” enabled (which you need if you are using a Display P3 display, like an iMac or MacBook Pro) the correction applied is wrong for matching an external BT.1886 monitor.

Confirm.
In new RCM Gamma 2.4 and Gamma 2.2 have linear segment near black now.

I’m not seeing evidence of this. An RCM (or OFX Color Space) conversion from linear to 2.4 gamma can be inverted using a gamma colour correction.

What makes you think this is the case?

I have to say also that I personally am not a fan of defaulting to Rec.709 (scene) as the timeline colour space. If you have “Use Mac display color profiles for viewers” enabled (which you need if you are using a Display P3 display, like an iMac or MacBook Pro) the correction applied is wrong for matching an external BT.1886 monitor.

I'm guessing you're referring to a non-color managed workflow here?

In a color managed workflow, this would/should ideally be handled at the output (Rec.709 Gamma 2.4), not on the timeline level.

Indeed. I’m talking about the default way Resolve currently starts up in non colour managed mode, with the timeline colour space set to Rec.709 (scene).

Have to admit I'm not a frequent Mac user. If that's the case, then the default should probably be Gamma 2.4 for non-color managed workflows. But in RCM the default timeline should still be Rec.709 Scene in my humble opinion.

Unfortunately even latest Beta 8 still has the issue of incorrect Gamma 2.4

Gamma 2.2 has always been fine.

What makes you think this is the case?

I compared conversions from gamma 2.4 / 2.2 / Rec709 / sRGB to LogС / Gamma 2.2 / Gamma 2.4 / Rec709 / sRGB / ST2084 in all combinations in DaVinci Color Managed with all the DRT things turned off to the same conversions in Color Space Transform effect. I used Gray Scale gradient for this.

You're absolutely right that the gamma has changed! I just double checked and even Gamma 2.2 has had a shift!


I've created an archive of relevant RCM and RCM2 Gamma projects to show the variances...

https://gofile.io/d/kL4F9S

When you say “BT.1886 expects…” that is really only in the simplest form of direct legacy television camera direct to display system, with no grading applied.

Grading makes no difference in this imho. What people do during grading is implicitly compensating for encoding mismatch with their grade.

Addressed an issue with gamma shift when using Resolve color management without selecting an output DRT.

Thanks for this. The gamma shift issues are now resolved.

I have noticed though that when DRT is enabled the default DaVinci tone mapping is quite aggressive and will push the highlights and shadows significantly lower.

In the case of highlights, it appears they are maxing out just under 95 IRE at Data Levels.

I'll probably raise a separate thread for DRT related issues