How to handle the ACES white point

clemens · December 9, 2019, 5:13pm

Hi,

I am pipeline TD in a CG movie company where we are currently planning to implement ACES and to render in ACEScg. So far, we have been rendering in scene-linear rec709 D65 using 1D tone mapping for viewing. For lighting, we often use HDR skies that are stored in linear rec709 D65 exr files.

Now, which input transform does such a sky need for the ACEScg rendering space? In Maya’s SynColor I choose scene-linear Rec 709/sRGB. This transform directly sets the HDR’s D65 neutral axis to the ACES D60 neutral axis. If I take the ACEScg D60 rendering space for serious this means my HDR is shifted to yellow. But in Maya I don’t notice this effect because all default SynColor view transforms also directly map the ACES D60 white back to my monitor’s sRGB D65 white.

The same happens with OCIO. Here I chose lin_rec709 as input transform for the HDR sky. This maps R=G=B=1 in rec709 to R=G=B=1 in ACES, too and thus shifts my HDR to yellow. Again I don’t notice this when I’m using the sRGB (ACES) view transform instead of sRGB D60 sim. (ACES).

In my opinion in ACES there should be a linear rec709 D65 input transform by default which keeps the D65 chromaticity at x=0.3127, y=0.329. It may be aliased rec709 HDR so it’s clear that it’s not suitable for textures like albedo maps that need to adapt the white point. For naming consistency it may be suffixed D60 sim.

I know I’m free to customize SynColor and OCIO and add such an input transform. But I wonder if I’m the only one missing it. Am I going astray?

I see another approach how to regard the described D65 to D60 -> render -> D60 to D65 workflow. When I apply lin_rec709 to the HDR sky without using a D60 sim. for the viewer then I make two mistakes at once that cancel each other out. So effectively the rendering space isn’t ACEScg anymore but it becomes linear AP1 D65 instead. So the workflow is simply D65 -> render -> D65. This also applies to all situations where I don’t use a D60 sim. viewer on a D65 display. This is substantiated since color picking is done in Output - Rec.709 by default.

If my monitor is at D65, what does picking white mean?
With the color picking role set to Output - Rec.709 a pure monitor white is translated to R=G=B=1 in the rendering space. This is right for an albedo map but for a light source this is only right if the rendering space is also at D65. Once more this encourages the implicit use of a linear AP1 D65 rendering space, too.

In Nuke similar questions arise. When I read one of our old linear rec709 D65 renderings into Nuke the Utility - Linear - Rec.709 input transform simply adapts D65 white to the ACES D60 working space white. The original chromaticity is not preserved and the old rendering is shifted to yellow. But I won’t notice that as long as I use a D65 monitor without a D60 sim. display transform. Plus this works perfectly together with the newly created linear AP1 D65 renderings where R=G=B=1 represents my HDR sky’s D65 white.

This way I easily end up building a linear AP1 D65 color pipeline that’s labelled ACEScg without noticing it. I wonder if this is common practice?

In such a pipeline the images look too yellow when using a D60 sim. output transform. One might argue this is alright since in a dark cinema things look different. So for desktop preview you use non-sim, for cinema preview you use D60 sim. But in my opinion this approach establishes a pipeline with two white points: D65 for desktop and ACES D60 for cinema. In this sense the ACES D60 white point effectively becomes output referred. The concept of two white points will become obvious when I write to ACES2065-1 exr without correcting the D65 of my working space to ACES D60 and at the same time I write sRGB files without using the D60 sim. transform.

The way I expect ACES to work is that an ideal pure color pipeline without any artistic color decisions preserves the chromaticity of my HDR sky from the source file to the cinematic projection.

I see different ways to achieve this:

The following D60 aware implementation is not supported by default.
Also the Maya color picker is ambiguous:

D65 - D60 -> render@D60 -> view D60 sim. - D65
rendering@D60 -> compose@D60 -> view D60 sim. - D65
composition@D60 -> D60 sim. - sRGB.tiff
composition@D60 -> ACES2065-1 exr
ACES2065-1 exr -> grade@D60 -> project D60 sim. - DCI white

With monitors and surrounding calibrated to D60 I get rid of the ambiguous color picker:

D65 - D60 -> render@D60 -> view D60
rendering@D60 -> compose@D60 -> view D60
composition@D60 -> D60 sim. - sRGB.tiff
composition@D60 -> ACES2065-1 exr
ACES2065-1 exr -> grade@D60 -> project D60 sim. - DCI white

If I understand TB-2018-001 right then I’m free to set R=G=B to the display calibration white point and implement ACES this way:

D65 -> render@D65 -> view D65
rendering@D65 - compose@D65 -> view D65
composition@D65 -> sRGB.tiff
composition@D65 - D60 -> ACES2065-1 exr
ACES2065-1 exr -> grade@D60 -> project D60 sim. - DCI white

So, which way to go?

Clemens

stobenkin · December 9, 2019, 6:00pm

Welcome Clemens! Thanks for your first post. White points are a big issue we’re taking up in our development of ACES 2.0. I’m sure someone from the community will comment with some practical advice in the meantime.

Best,

Steve T
ACES Admin

Thomas_Mansencal · December 10, 2019, 7:07am

Hi Clemens,

I will sound pedantic but if the chromaticity coordinates are changing, it is not D65 anymore. You are meaning that there should be a transform that does not change the whitepoint right?

I’ll be pedantic again and even more so because I also fell in the same trap, for future reference, ACES Whitepoint is not D60, it is close but is not D60. I still sometimes forget to make the distinction when writing and I don’t like the fact it is named D60 all over the place in CTL, only serves perpetuating confusion. @Alexander_Forsythe wrote a document that I will try to dig explaining the difference.

There are a few things at play here, but to make things easier I think that you should compare the ACES Whitepoint like that of the ICC PCS, i.e. D50. This is the adopted whitepoint for work, so all the encodings that connect to the working space, e.g. ACEScg, chromatically adapt to it, so that achromatic colours stay achromatic. In ICC, if you were to go from sRGB to DCI-P3, the ICC engine would effectively go through D65 --> D50 --> DCI-P3 Whitepoint.

As per my previous comment, those are not mistakes, quite the opposite, this is how the system is designed to work.

This is a great discussion point! To me, at the end of the day, it is conceptually the same thing, whether the light is irradiating directly to the virtual camera sensor (and is visible via say an area light), or its illumination is modulated via the reflectance of a surface, it is still light inbound to the virtual camera sensor. Because you are not working spectrally, you still have to adopt an encoding whitepoint when picking your colours. In that context, and because you are working in the sRGB/BT.709 colour picking white means the adopted D65 whitepoint. The values are then chromatically adapted to the ACES Whitepoint once piped into the ACES working space so that your creative intent is preserved.

This is not correct and actually the opposite happens, the original chromaticity coordinates ARE preserved because when you specify RGB values, it is always with respect to a given illuminant. When you perform chromatic adaptation of RGB values from a source illuminant, e.g. D65 to a target illuminant, e.g. D50, the new RGB values are encoded and specified relative to the target illuminant, i.e. D50. See that as space transformation, the RGB values are effectively encoded with different numbers but they are still representing the same quantities, only expressed into a different space.

Note that, almost all the relevant colour models in colour science, e.g. CIE XYZ, CIE Lab, CIE Luv, etc…, have an explicit illuminant input (or an implicit hardcoded one that is known and documented).

The D60 sim. ODTs are designed for typically dark to dim surround and assume that the observer is adapted to ≈D60. You would need to use them accordingly to your viewing conditions.

Abstracting the various effects of the tonescale(s) and the RRT sweeteners, this is what is happening in the system.

As I mentioned it, you should really see ≈D60, as the ICC PCS D50 whitepoint, it is an encoding requirement. When one design a colour imaging system, its encodings need to specify a whitepoint. For ACES, ≈D60 was chosen because it was deemed appropriate for theatrical exhibition.

Hope that makes sense, sorry if I did not answer everything but I had the feeling I was starting to repeat myself

Cheers,

Thomas

clemens · December 10, 2019, 7:06pm

Hi Thomas,

thank you very much for your detailed answer!

Obviously, I have missed the concept. I have thought absolute xy chromaticity should stay the same throughout the whole color pipeline. But instead the neutral axis should stay neutral throughout the pipeline. That’s like the Nuke Colorspace node with the Bradford matrix turned on. With this in mind things start making sense to me.

For my HDR sky this means: I can use the lin_rec709 input transform since R=G=B in the sky maps to R=G=B in Maya’s ACEScg working space and again that’s R=G=B on the monitor. Same with compositing. Neutral stays neutral all the time no matter what the absolute xy chromaticity of the ACES white point is.

So normally the ACES white point is quite abstract and not visible to our artists in lighting and compositing. It’s just a virtual placeholder for the neutral axis. The only time when it comes to life and gets visible is when I’m using a D60 sim. ODT. This is only useful when I am chromatically adapted to the ACES white point, too. And the idea is that this is especially the case when I am in a cinema with it’s dim 48 cd/m2.

I hope I understand things correctly now, before I set up the conversion of some thousand Maya assets from linear Rec.709 to ACEScg.

Thanks a lot!
Clemens

Thomas_Mansencal · December 11, 2019, 7:22am

No worries and glad it was helpful!

That could be a way to see it, pun intended It is an encoding requirement that is also purposely appropriate for the operating context of the system. The ICC comparison with its PCS D50 whitepoint is the easiest analogy to go back to.