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