Color Space Transform crushing blacks?

Am I doing something wrong? It seems to me like DaVinci Resolve's Color Space Transform is crushing blacks when going to Rec.709 Gamma 2.4? Is this by design?

This is how it looks with simple ramp when transforming ARRI Wide Gamut LogC3 to Rec.709 Gamma 2.4, compared to ARRI's LUT.

AWG-LogC3-to-709.png (232.88 KiB) Viewed 2571 times

I may be wrong but I don't think that's exclusive to LogC3, it's how the DRT works. Viewing the ramp's behavior without considering the (camera) black point, ie. a 0-1 ramp, the resulting curve will look odd. It's perhaps more interesting to know why the ARRI LUT doesn't "clip". It would mean that it doesn't map camera black to display black?

The CST tool will destructively clip/crush when transforming to a smaller gamma. This is why you always have to do your exposure/contrast adjustments prior to of the 709 CST.

So if your expectation is that a CST is non-destructive vs a LUT, that is simply not the case.

The CST tool will destructively clip/crush when transforming to a smaller gamma. This is why you always have to do your exposure/contrast adjustments prior to of the 709 CST.

So if your expectation is that a CST is non-destructive vs a LUT, that is simply not the case.

This is not quite accurate. A CST is pure math using 32-bit floating point. a LUT's accuracy is only limited to the sampling points provided... everything else is interpolation (aka guesstimation). They are worlds apart.

The behavior you're talking about is only manifest from RCMv2 with DRTs that also have forward/inverse OOTF applied by default.

I suspect this is what the OP is also observing.

Also worth noting is that most manufacturer LUTs have some degree of artistic license baked into the LUT as there would be some form of gamut/tone mapping applied in addition to color tweaks for aesthetic purposes.

Thanks for the replies guys.

The behavior you're talking about is only manifest from RCMv2 with DRTs that also have forward/inverse OOTF applied by default.

I suspect this is what the OP is also observing.

I used a CST in a DaVinci YRGB project to convert from ARRI Wide Gamut LogC3 to Rec.709 Gamma 2.4, which by default applies a forward OOTF since it is going from scene to display. Then I compared this to ARRI's LUT.

I'm not saying DaVinci is doing anything wrong here when Tone Mapping is set to DaVinci or Luminance mapping, I'm just wondering why blacks aren't rolled off smoother, like the ARRI LUT is doing.

This is what CST Tone Mapping set to "Simple" is doing.

Screenshot 2023-01-03 at 17.54.17.png (538.28 KiB) Viewed 2444 times

Just for reference. This is what ACES Transform is doing.

Screenshot 2023-01-03 at 19.00.47.png (322.82 KiB) Viewed 2438 times

Testing on a linear ramp is far from real world, but still interesting to see the different approaches on converting ARRI LogC3 to Rec.709.

Here is DaVinci Wide Gamut Intermediate to Rec.709 Gamma 2.4.

Screenshot 2023-01-03 at 19.20.33.png (494.45 KiB) Viewed 2425 times

Am I doing something wrong? It seems to me like DaVinci Resolve's Color Space Transform is crushing blacks when going to Rec.709 Gamma 2.4? Is this by design?

What if you turn the Forward OOTF off? What happens if you change the Tone-Mapping Method? I've played around with those on occasion, and sometimes the default isn't as good as the other selections. I think there's some room to play around there provided the end results are good and give you enough range. I'm more nervous about Input Colorspace than Input Gamma -- the latter you can always tweak, but the former (to me) is more critical.

There's also no crime in doing a slight contrast correction prior to the CST if it's a minor adjustment, like bumping the shadows (what I call the "toe" of the signal) up a little bit. I try not to adjust color there, but I'll change level a bit on occasion if something wonky is happening.

What if you turn the Forward OOTF off? What happens if you change the Tone-Mapping Method? I've played around with those on occasion, and sometimes the default isn't as good as the other selections. I think there's some room to play around there provided the end results are good and give you enough range. I'm more nervous about Input Colorspace than Input Gamma -- the latter you can always tweak, but the former (to me) is more critical.

Thanks for the reply, Marc. Turning off Forward OOTF breaks the curve completely. As the CST OOTF "tool tip" implies in Resolve, this should be turned on when converting from Scene to Display Referred.

CST-OOTF.png (84.3 KiB) Viewed 2358 times

The tone curve for DaVinci and Luminance is very similar, but look exactly the same in the blacks. As mentioned previously, the Simple tone mapping rolls off the blacks similar to what the ARRI LUT is doing.

Side note: I also find it a bit strange how the term Gamma is still used widely in our industry for Log based transfer functions. Gamma is a pure power function.

The latest DaVinci Resolve ACES 2.0 ODT candidate for Rec.709 (rev027) improves the blacks for ACES quite a bit as well, but looks quite similar to what the DaVinci Resolve CST with DaVinci/Luminance tone mapping applied is doing.

ACES-709-ODT-vs-ACES2.0-rev027-709-ODT.png (639.3 KiB) Viewed 2344 times

The fact that the curve is 'shifted' in my mind makes sense because a code value of 0 is below the black level of the camera log encoding. Log curves that don't have a toe don't 'suffer' from this because they continue through 0. Like DaVinci Intermediate or ACEScc.

Interesting to see that 'Simple' tone mapping does map 0 to black and lifts from there if the input is a curve with a toe.

ACES 2.0 candidates have a much more pleasing tone scale over 1.3 and looks to come out of black smoother. But I'm not sure we should expect the result of that ARRI LUT which lifts black. Evaluating a linear ramp from 0-1 doesn't represent a log curve by any means so the resulting curve after tone map can't really tell you anything.

Here are the results when transforming a ramp that does follow the LogC encoding. I used Cullen Kelly's Exposure Chart DCTL for this. And of course choosing a different input ramp like ACEScc and then transforming that to display would result in the exact same curve on the scopes.

Artboard 1.png (366.89 KiB) Viewed 2327 times

Awesome. Thanks so much, Shebanjah! Makes sense indeed.

Cullen's Exposure Chart DCTL is awesome.

Actually, it would be nice if Blackmagic could create a built-in chart generator that supports all camera encoding curves that RCM supports. I mean, they already have generators for Color Bars, 10 Step gray scale, and Gray Scale ramp.

DaVinci-Resolve-Generators.png (140.96 KiB) Viewed 2302 times

Now it makes me wonder why ARRI is lifting blacks like they do in their LUT, hehe.

Now it makes me wonder why ARRI is lifting blacks like they do in their LUT, hehe.

Perhaps it was never meant to be used in post. It could well be a camera LUT designed for SDI feed with video levels to a monitor? Or it was just adjusted to taste by BMD. We can't really trace it's origins, but if I grab the official ARRI LUT generated on their site it maps much closer to black like other DRTs. ARRI's LUT should resemble that of their ALF-2 DRT without any other sauce.