ACES 2.0 CAM DRT Development

[jeffrey.d.mathias]

Derek, have you also compared ARRI Reveal with CAM DRT v35 in HDR? If so, are the comparisons similar in their differences between SDR and HDR, or what are the differences?

Also, does ARRI Reveal only work with ARRI Wide or can it be applied to DaVinci Wide from Braw? And where did you get ARRI Reveal to apply to the sample frames? The ALEXA 35 Supporting Tools & Software page indicates that Reveal is supported in DaVinci.

Shebbe, I am glad you are looking at comparing various ‘renderings.’ Same questions.

Thanks

[Shebbe]

@jeffrey.d.mathias

Also, does ARRI Reveal only work with ARRI Wide or can it be applied to DaVinci Wide from Braw? And where did you get ARRI Reveal to apply to the sample frames? The ALEXA 35 Supporting Tools & Software page indicates that Reveal is supported in DaVinci.

What I did for comparing was using ARRI’s AWG4/LogC4 to Rec.709 conversion LUT with a pre-conversion for the ACES exrs to LogC4. I’d imagine you could do the same for .braw files in that regard.

[priikone (Pekka Riikonen)]

@nick

it is fairly simple to make it so the compression slope gets steeper instead of shallower as the cusp gets more saturated.

I quickly implemented this and have been looking at some images. I would say it works well, and in some respects perhaps better than the previous one. It visibly lightens gamut mapped blues and magentas, but I don’t consider it any real improvement when it comes to issues with blue, just a lighter mapping.

It does desaturate mapped yellows faster than before, and perhaps a tad too fast (in comparison to older versions, or in comparison to ARRI Reveal), which I think happens because darker yellows get projected with shallower (or more upward) angle now.

But the interesting question will be whether this makes the SDR appearance match closer with different gamuts when it comes to images like the ARRI bar image.

[nick (Nick Shaw)]

@priikone

It does desaturate mapped yellows faster than before, and perhaps a tad too fast (in comparison to older versions, or in comparison to ARRI Reveal), which I think happens because darker yellows get projected with shallower (or more upward) angle now.

There is of course infinite possible variation within this approach. The simple inversion I have done means that as well as steepness changing between gamuts, depending on the M value of their cusps, the change of steepness within an individual gamut happens in the opposite direction. So the slope is steeper for hues with larger cusp M values, whereas previously it was shallower for them.

This would explain the yellow behaviour you describe, and if it is not desirable we could try something different.

For example, we could still multiply by the cusp M value, as we did before, but divide by an M value which is a single global value for the gamut. Perhaps something like the M value of the green primary, for example. You would then need an appropriate multiplier to get things back to the previous order of magnitude, and may or may not need to include J_{max}.

[priikone (Pekka Riikonen)]

@nick

There is of course infinite possible variation within this approach.

Indeed, and this is all good work, Nick. I think it’s good to get more control for the gamut mapper and especially for the projection. I’ve felt that there isn’t enough control at the moment. For the yellow with the high cusp, and similarly for cyan, it’s not far and probably small adjustment is going to make visible difference. And with more control we can probably get the matches between different gamuts closer as well.

[priikone (Pekka Riikonen)]

@Shebbe

On closer look it seems to me that ARRI Reveal is rendering darks a bit darker making the color difference less noticeable resulting in less of a cast. Here I took a look at it with two other renderings. I used v034 because I didn’t install v035 yet but I don’t think the rendering changed there in that regard? In any case I do like how CAM DRT is rendering the bottom end.

ARRI Reveal looks great, but it also has a look built in. Their colors match the old transforms really well, they seem to have a built in look for skin tones, and they do interesting stuff in shadows. CAM DRT has more saturated reds and probably overall a bit more saturated look out of the box. If people prefer less saturated look for CAM DRT that is an easy adjustment to make. Personally I would lower the saturation a bit. The other things, like darker red, darker green, lighter blue, they can be done in LMT.

Here’s CAM DRT v035 with a simple LMT with HSV adjustment for blue hue and value:

And here’s CAM DRT v034 with the alternative compress mode and an LMT for the blue:

And ARRI Reveal:

[meleshkevich (Anton Meleshkevich)]

No one asked, but
A bit of info regarding how DaVinci DRT works:
It uses per-channel tone mapping. But flare compensation (which, in DaVinci DRT, is most likely identical to rec709 EOTF linear segment near black) is undone after tone mapping and prior to primaries conversion, and then added after again. Unlike, for example, K1S1 where linearization of the tone-mapped image is done by using display EOTF (gamma 2.4 for example), keeping flare compensation unchanged at the input to the matrix multiplication.

[Shebbe]

@priikone

CAM DRT has more saturated reds and probably overall a bit more saturated look out of the box. If people prefer less saturated look for CAM DRT that is an easy adjustment to make. Personally I would lower the saturation a bit. The other things, like darker red, darker green, lighter blue, they can be done in LMT.

Here’s CAM DRT v035 with a simple LMT with HSV adjustment for blue hue and value:

Some thoughts I have:

• I think the current saturation is great, but slightly less saturation as a starting point wouldn’t be that offensive to me if that’s what the majority would want.
• The v035 with LMT for blue example looks very good to me. It solves the harsh splotches seen on the blue lit wall and ceiling but retains more brightness information compared to the v034 example or ARRI Reveal. To me that looks like a good middle ground to aim for. I can’t pull up the HDR version right now but from memory it would be a better match with that as well.

About the LMTs… I sometimes hear it brought up as possible options to provide different renderings shipping with ACES2.0, is that correct?
To me the example you showed should be part of the rendering already. It would be interesting to have several ‘technical’ looks but if I have to look a it practically, how easy will tracking different rendering choices really be? Most software with OCIO support don’t have good ways to select OCIOLooks from the viewer so you’d have to do custom OCIO setups. The only one I know of that does have it is Blender. BMD, Filmlight SGO etc. can obviously implement it in their native software environment but it gets trickier outside the grading/finishing area right?

I’m not involved with big productions so maybe my vision is totally warped… but if an LMT in a project becomes part of the look a colorist might do, doesn’t it already become part of the creative vision for that project? So what would be the point of having it as an option for ACES’ rendering itself?

I guess what I’m trying to say is that I feel that if ACES2.0 would provide LMTs they should only be really creative looks and not a mechanism to alter the rendering of ACES itself. With really creative looks everyone can be more aware that it has a creative purpose and (depending on the look) it’s also very likely to spot whether such a look is applied on the image or not anywhere in the pipeline.

And maybe the more important question. If there is a need to provide ‘technical’ LMTs for ACES2.0. Wouldn’t that mean we’re not happy enough with the default rendering?

I hope that made any sense.

[nick (Nick Shaw)]

@meleshkevich

Unlike, for example, K1S1 where linearization of the tone-mapped image is done by using display EOTF (gamma 2.4 for example), keeping flare compensation unchanged at the input to the matrix multiplication.

The K1S1 in fact does not use a simple power function but "something that approximates the power function with a limited slope around 0 ", as described by @hbrendel in this post.

[cameronrad]

Oddly I have two versions of the K1S1 LUT with different curves.

One labeled Classic from the Arri LogC3 LUT packages found here

Another one labeled K1S1 that I believe I got from either Nuke or possibly the old LUT generator. I think Resolve includes this one as well.

[Derek]

@jeffrey.d.mathias

Derek, have you also compared ARRI Reveal with CAM DRT v35 in HDR? If so, are the comparisons similar in their differences between SDR and HDR, or what are the differences?

Yes I have. I observe the same differences in HDR as I do in SDR.

@jeffrey.d.mathias

Also, does ARRI Reveal only work with ARRI Wide or can it be applied to DaVinci Wide from Braw? And where did you get ARRI Reveal to apply to the sample frames?

I did it in Nuke, so I’m afraid I wont be much help with Davinci!

[Derek]

I agree with @Shebbe that the saturation for CAM DRT is great. I’m also not really sure that anything should be changed about red as far as its saturation or brightness goes.

What I would wish to adopt from ARRI Reveal for red is that red stayed red longer, and did not go to pink (path to white) quite as quickly as it does now.

For blue, I don’t think it should shift to magenta. Blue should be blue, a la OKlab.

As far as the blues being brighter, that’s a discussion of color appearance. My observation is that looking at ARRI Reveal all these colors appear to me to have the same brightness:

…and in CAM DRT the blue appears to me to be darker than the other colors:

should that be “fixed” in CAM DRT? I really don’t know, but I think it could be worth discussing.

[nick (Nick Shaw)]

@cameronrad

Oddly I have two versions of the K1S1 LUT with different curves.

Apologies that this is slightly off topic, but I can explain the difference.

The original ARRI LUT Generator web page could generate a range of LUTs. As well as the option to control the contrast of the curve, and generate e.g. a K2S3 LUT, the downloaded LUT sets included a “photometric” version, which used the underlying curve which mapped 0.0 in to 0.0 out and 1.0 in to 1.0 out, and a set of different “normalized” curves for each EI setting which rescaled the curve to set the black level, and ensure the curve hit 1.0 at the exact clipping point at that particular EI.

The EI dependent version was what was applied on the monitor output of the camera, so I always thought it slightly odd that the photometric K1S1 became the default used in post, as it doesn’t exactly match what would have been seen on set, and has a rather raised black level. I guess ARRI thought the same, as what they now ship as the “classic” LUT appears to be more like the EI800 variant, which I always considered a better default.

End of sidetrack!

[cameronrad]

Ahhh!!! That explains a lot!! Thank you!!

[Phototechnica (Christopher Jerome)]

Thanks again for your continued work on this Nick, this appears to be one of the most critical steps in the whole transform, so any and all tweaks need to be tried.

The part that hurt my head the most with the P3 clipping and the 709 not clipping the green was not that the different gamuts gave different results, it was that 709 Limited P3 gave different results in P3!

The idea to blend the two images was not immediately useful to fix the problem, but it suggested that an intermediate abstract gamut might be a useful idea.

From the perspective of 709 limited P3, the 709 is just an abstract gamut, so maybe another “ideal” abstract gamut could offer the desired properties.

here are two examples, roughly based on 709 near “Arri Bar green” (P3 cusp is not accurate, but could represent any larger display gamut), and the sample is roughly “Arri Bar green” values for reference.

The first is very simple, close to an average, but it specifically has a cusp with a higher J value than 709.

The second one was done with a simple bezier (not sure if that is too complex for current options), but something like that may help with smoothness.

Only suggesting any of this because the gamut mapper appears sensitive to the cusp position and the results from P3 were so unintuitive compared to 709.

Probably not a solution, given the requirements to map to any display, but the idea has come up a few times so it might be a useful experiment to see what an adjusted “virtual cusp” might have on the output.

At the very least, It may help determine the ideal behaviour of the gamut mapper.

[priikone (Pekka Riikonen)]

@Phototechnica

The second one was done with a simple bezier (not sure if that is too complex for current options), but something like that may help with smoothness.

This is what’s happening with the current transform by default with the cusp smoothing enabled. The actual shape for the gamut mapping intersection is a rounded shape like the one in your example.

@Phototechnica

The idea to blend the two images was not immediately useful to fix the problem, but it suggested that an intermediate abstract gamut might be a useful idea.

I tested using P3 as the limiting gamut for Rec.709, clipping the end result to Rec.709. As expected, the image mostly looks the same, and fine, but there are more “traditional” type skews, and especially visible with green. Here’s few comparison images. First image is v035 Rec.709, second is v035 Rec.709 with P3 as mapping gamut, and third one is ARRI Reveal Rec.709.

EDIT: When comparing this change to P3 rendering, I noticed the Rec.709 match is visibly closer to P3 colors, including the highly saturated green.

[TooDee (Daniel Brylka)]

Hi Derek,

how and which type of HDR did you render out from rev035?

I tried to use the OCIO config, but I did not had any success yet.

I usually take the 1-1-1 tagged QT in FCPX and use a colorspace override to see the result in HDR. The transform in the OCIO config does not even specify if it is HLG or PQ. I am confused.

With the OCIOv2 studio config from Nuke 14 this workflow works without any issue. Same for ARRI Reveal via a LUT or Truelight T-Cam.

Additional failed test:

I was hoping to render out a HDR file with these setting. But no success. At least I know that it should be PQ and not HLG.

@alexfry Do you know what I am doing wrong?

[Derek]

Hi Daniel,

I’m probably not going to be able to help much with this unfortunately. I’m not writing out to HDR, but simply viewing the HDR on my Mac Pro M1 from inside of Nuke.

In case it’s helpful, in Nuke I’m using the Nuke node for the CAM_DRTv35 and have it set to 1000 peak luminance, output encoding sRGB/P3-D65 (which is what a MacPro uses, but would be different in your case), and clamp output off.

[TooDee (Daniel Brylka)]

ah ok, thanks Derek.

1000 nits peak makes sense of course. I oversaw this setting.
But the result clip still looks wrong. There must be another value missing for PQ HDR.

I wonder why I am not successful with the LUT from the OCIO config.

[Derek]

Might help to have a look at the OCIO bake LUT script on @alexfry 's repo to see how those LUTs were made. Here’s a screenshot (from v32):