ACES 2.0 Output Rendering

[prolost (Stu Maschwitz)]

I’ve been testing ACES 2.0 quite a bit now that it’s included with Resolve 20 Public Beta. I threw an old example image at it and was a little surprised at the results.

The image is an ACEScg EXR rendered in Redshift, and it’s certainly designed to be a somewhat tricky case.

Here it is transformed to Rec. 709 using ACES 1.2:

The red ball is lit with a blue light on the left. A red light on the right illuminates the blue and yellow balls. The light above is neutral. I used this image to show how rendering in ACES AP1 helps with more accurately portraying the color cross-talk in situations like this.

Here’s the same image in ACES 2.0, ACEScg to Rec. 709 with reference gamut compression:

I can see things here that seem to align with the stated goals of the Output Transforms team: less hew bending in highlights, less subjective contrast, and of course substantially less posterization. But I was surprised to see the yellow ball exhibit almost no yellowness.

Just for fun, here’s the popular 2499 DRT DCTL at its default settings:

So much about this is subjectively adjusted that it’s barely a comparison — the colors are quite liberally modified in ways that align with modern look development tastes. That said, you sure can tell what color the yellow ball is supposed to be.

Here’s a Dropbox link to the EXR if anyone would like to have a go: acesDemo_05_aces_i4.0000.exr

So many asterisks here: I designed this shot under an ACES 1.x view transform, so I lit it to look good there. Maybe this is one of those cases where the “yellow” ball really isn’t yellow at all in RGB terms, I just happen to know that it’s yellow because I built it. Does the red-lit side of the ball only look yellow for the same reason that the core of the floor reflection from the red light also looks yellow? Do I happen to like it when red lights blow out through orange and yellow? Is it fair that ACES should consider that a creative look decision rather than an in-built characteristic of a dispassionate view transform?

One more image for good measure: Here’s the ACEScg to Rec. 709 conversion done using Resolve’s CST node. Default settings for DaVinci Tone Mapping, default settings for Saturation Compression Gamut Mapping:

Would love any thoughts from folks on this comparison.

-Stu

[shebbe (Shebanjah Klaasen)]

I’d love to have a look at the render. The Dropbox link mentioned doesn’t seem to have an actual link attached. Could you double check this?

[prolost (Stu Maschwitz)]

Sorry about that, I was able to edit the post and I believe the link works now.

[TooDee (Daniel Brylka)]

I had a look at your EXR file in Nuke and viewed it through some more view transforms/DRTs including ACES 2.0 (LUT bake config), TCAMv3, OpenDRT and AgX.
The yellow ball is not really looking yellow in most of the transforms out of the box.

You mentioned that you used for ACES 2.0 in Resolve the:

Here’s the same image in ACES 2.0, ACEScg to Rec. 709 with reference gamut compression:

As your rendered values are all positive in ACEScg, the RGC should not have any effect at all.

I deleted my example, because this morning I saw that I used the wrong ODT in Resolve 20. The list is so long, it seems I clicked actually on a D60 ODT instead of a D65. My bad…

[prolost (Stu Maschwitz)]

As your rendered values are all positive in ACEScg, the RGC should not have any effect at all.

It does have an effect though, I believe because some of the ACEScg values are out-of gamut in the destination space of Rec. 709.

I think you’re right though that the yellow ball, where illuminated by the red light, is in fact quite red by any objective measure. So I think maybe the ACES 2.0 point of view on this ball may well be that to render that side of it yellow was in fact a hue-skewing bug. Here’s the same scene, same ODT, but minus two stops in ACEScg:

-Stu

[TooDee (Daniel Brylka)]

Yes, you are right, I checked your EXR in Nuke again and the RGC does have an effect on the resulting image. I did not expect that.

[priikone (Pekka Riikonen)]

It’s recommended to keep RGC disabled with ACES2 as it has a built-in gamut mapper. Use it only if you find that you need it. RGC also skews colors toward the primaries (red in this case) which is the opposite of what you were looking to happen here.

Here’s the image without RGC (sRGB):

And here with a small grade to skew the yellow a bit:

[Thomas_Mansencal]

To push values inside ACEScg/AP1 gracefully and not clip them, the boundary has to be “fuzzy” / “soft”, thus the RGC will also affect values close to it within AP1. You should also be able to verify that repeated use will modify values again.

[prolost (Stu Maschwitz)]

@priikone

It’s recommended to keep RGC disabled with ACES2 as it has a built-in gamut mapper. Use it only if you find that you need it. RGC also skews colors toward the primaries (red in this case) which is the opposite of what you were looking to happen here.

Thanks, that’s helpful. I rendered out my own version with and without, redundant to yours but with my labels.

[TooDee (Daniel Brylka)]

@priikone

It’s recommended to keep RGC disabled with ACES2 as it has a built-in gamut mapper. Use it only if you find that you need it. RGC also skews colors toward the primaries (red in this case) which is the opposite of what you were looking to happen here.

Maybe someone at Blackmagic should know about this? When you switch to ACES 2.0, the RGC is enabled by default at least with my installation.

[TooDee (Daniel Brylka)]

Unless I made a mistake with the plot or @prolost with the render settings, no pixel seems to be outside AP1 and therefore no pixels needs to be “pushed” inside?
And yes, two OCIOLookTransform nodes in a row do change the image result even more than one node.

acesDemo_05_aces_i4.0000.exr

[priikone (Pekka Riikonen)]

@TooDee

Maybe someone at Blackmagic should know about this? When you switch to ACES 2.0, the RGC is enabled by default at least with my installation.

I don’t think the official documentation for ACES2 is out yet (?) but I came away with the assumption that we’d recommend RGC be disabled by default in ACES2 as it’s not needed, and because it was designed for ACES1.

@TooDee

no pixel seems to be outside AP1 and therefore no pixels needs to be “pushed” inside?

Since ACES1 doesn’t have gamut mapper (unlike ACES2) the threshold for the compression has to be within the AP1 to get colors pulled into AP1. Here’s the threshold:

The compression starts from the threshold and only the colors within the threshold are guaranteed to stay unchanged. See all the details in Reference Gamut Compression Specification.

[nick (Nick Shaw)]

@prolost

t does have an effect though, I believe because some of the ACEScg values are out-of gamut in the destination space of Rec. 709.

The RGC is a scene side gamut compression, and is independent of the destination display gamut.

[LeeNiederkofler (Niederkofler Lee)]

Rendered via OpenDRT. The ball looks quite yellow to me compared to the ACES 2.0 version.

EDIT: As Jed pointed out below, this is not the current OpenDRT version.
I created this with an older OpenDRT version I had installed on my Ipad.

[prolost (Stu Maschwitz)]

@LeeNiederkofler

Rendered via OpenDRT. The ball looks quite yellow to me compared to the ACES 2.0 version.

I like the way this looks, although I’m surprised at how dim the light boxes are rendered. The red light has ACEScg RGB values of 67.4, 9.2, 3.2, and the blue one is 11.5, 12.1, 135.4. Bright colors to render as pastels!

[prolost (Stu Maschwitz)]

@TooDee

Unless I made a mistake with the plot…

How did you generate that plot? I’d like to investigate this as it seems odd that the values are clipped so distinctly to a subset of AP1.

[prolost (Stu Maschwitz)]

@priikone

It’s recommended to keep RGC disabled with ACES2 as it has a built-in gamut mapper. Use it only if you find that you need it. RGC also skews colors toward the primaries (red in this case) which is the opposite of what you were looking to happen here.

@nick

The RGC is a scene side gamut compression, and is independent of the destination display gamut.

Thanks Pekka and Nick, this seems like an important point, and one that I had missed. If I’m understanding correctly, RGC is designed for easing colors outside of AP1 into AP1 for subsequent grading etc., not for helping with any given display transform.

So RGC might be useful when, say, bringing colorful Arri LogC4 footage into ACEScct for grading?

This is different, I believe, from how Gamut Mapping in Resolve Color Management works. My understanding is that here Gamut Mapping is typically used to prevent saturated working space colors from clipping harshly when rendered to a smaller output space.

[TooDee (Daniel Brylka)]

Colour Science for Python

When you have it installed , I can post the commands that I used to generate the plot.

Someone here on the forum made also kind of a web interface version where you can upload the EXR and get a plot. I am sorry, but it was a while ago… I don’t remember.

The plot looks a bit odd, I was thinking the same.

[flord (Francois Lord)]

You can also use the Plot Chromaticity tool from this collection in Nuke to do it quickly.

GitHub - jedypod/nuke-colortools: A collection of tools for Nuke related to color...

[doug_walker]

Daniel, was your chromaticity plot supposed to be of the source image? It doesn’t look right if so, there are definitely colors on the red ball that are outside of AP1. I’m attaching a graph of what I’m seeing for the xy values of the source image.

The circle is for a point on the yellow sphere just to the left of the highlight, where I measure an ACES2065-1 value of [5.2, 0.63, 0.098]. The xy chromaticity of that is inside AP1 but outside the P3 gamut. It’s [10.1, -0.15, 0.11] in P3, a bit below the red corner. So this clearly is a very saturated and bright red-orange source color. It’s essentially a reflection of a red light off a glossy surface.

When I look at the ACES 2.0 HDR 1000 nits (P3 D65) rendering of the yellow ball on an HDR monitor, it looks like what I think one would want it to look like. Namely, a very bright and saturated orange color that clearly shows the impact of the red window on the yellow ball. ACES 2 does a great job on this image in HDR, much better than the ACES 1.x HDR.

For the ACES 2.0 Rec.709 rendering, the red channel is maxed to 1 at that pixel, so it is on the top face of the gamut. But I agree it looks a bit desaturated, so the question is whether it’s in the best place on that part of the gamut surface.

As we all know, whenever you’re gamut mapping a color, there are three basic variables to trade off: lightness, saturation, and hue. I think the key thing to keep in mind with the gamut mapping in ACES 2 is that (in my understanding) it strictly preserves the hue of colors (inside AP1), so it is only trading off lightness and saturation.

This is sometimes an issue when gamut mapping yellow colors because, if one is not willing to introduce some hue error, you may need to desaturate quite a lot. This is due to the particular shape of the gamut surface around yellow.

Additionally, I believe ACES 2 ensures that all colors desaturate to white as they get bright enough. I’m not sure how much of a factor it is in this case, but it is a very bright color. The red window is outside the P3 gamut too and all of these renderings are bringing it towards white, so it’s natural for the reflections to be doing that to some extent.

ACES 1 and the other renderings being shown here bend the actual hue somewhat toward green in order to preserve saturation. (As is shown in the -2EV image above, the true hue is more orange.) They are also reducing lightness quite a lot for a color with a red channel above 5. Though I agree that it does look more pleasing on this extreme image.

It is difficult to draw too many conclusions from these CG tests with so many values extending outside P3. Should it look more like a reflection of a red window, desaturating towards white, or a yellow ball? I think the former is probably more accurate, even if the latter may be more pleasing. In SDR there is probably no really satisfying way to give a sense of what this image looks like in HDR.

That said, I’ve certainly found other images where the SDR rendering would be more pleasing if it allowed a little hue error. But I do respect the principled philosophy of strictly preserving hue and in HDR especially it seems to be working quite well.

It’s an interesting test image, thanks for sharing Stu!

Doug