Maya, ACES and Custom Look Views

Hello, I successfully made an OCIO ACES v1.0.3 Custom View for Maya with a custom look in the form of a ASC_CDL ccc file, but I actually wanted to use CDL looks and load the SOP with LookTransform to no avail. I checked the documentation but there’s no keys for the !<LookTransform>, I tried !<LookTransform> {lookname} but all I get is “lookname is not a known key”.

Another concern is that in RenderView white highlights are actually grey, which is a bit strange. It’s impossible to burn some highlights and make them look white as supposed, I know it’s due to the RRT highlights roll-off as I could find in this thread with the same issue, but still this is a bit undesired in my opinion it’s like baking an analog medium look (like a PFE) when the output might even end in an analog medium (film, projectors…), doubling the effect.
As a workaround I made a “Utility - sRGB - Texture” Viewer Transform but I would like to know your opinion on this.

Finally I would like to know the difference from ASC CDL and CLF, reading the documentation it seems that CLF has a bigger scope where you can define in an XML all the color processes in a node workflow including 1D Luts, 3D Luts, CDL and more. But I wonder how this workflow helps in the pipeline, I see no support for it in Maya, Nuke, Resolve…

Thanks for the help!

You can get fully blown highlights through an ACES Output Transform. You just need to have ACES values at 16.3 or above (for SDR OTs). An sRGB - Texture based output transform is treating ACES as if it is output-referred, and will map diffuse white (ACES 1.0) to peak white, which is not correct, and therefore not what subsequent ACES processing will do. If you are working in ACES, you should be working with scene referred image data which goes above 1.0.

CLF is much more capable than ASC CDL, but you are right that it is not yet as widely implemented as would be ideal. OCIO 2.0 will include CLF support, and Resolve 15 already supports it (read only).

1 Like

Values above 16.3 are very rare unless you have a light source on shot or a very very bright spot from shiny metal. For reference please check this image, the highlights in this metal shader maps to a value of 0.6 even in the brightest version of the ACES samples.
If for artistic reasons I pump the light strength up everything else would break apart.
If I understand that what the RRT does is an artistic take of an HDR normalization I think I could try different approaches used in games, so instead of “sRGB - Texture” (which actually transforms the image as if I used old Maya Rec.709/sRGB viewer lut) I would like to try different tonemappers like John Hable’s filmic tonemapping. Do you think this is incorrect? I would like to know what makes the RRT so special, some info on the shapers and how they relate to the RRT would be also very helpful.

The RRT is not ‘special’. It is just a standard which is implemented in a wide range of software, so you know that if you (correctly) use ACES in one application, it should look the same when you use it in a different one. ACES is only one colour managed process, and you are of course free to use others. But if ACES is being used for the DI, it makes sense to preview that in CG and comp. Using different display transforms for viewing at different points is a recipe for problems later on!

I am not a 3D expert, so cannot comment in detail about the way things should be set up in Maya. But to give you a few example, ACES 1.0 should map to about 81% through the ACES sRGB Output Transform; 4.0 should map to about 95.5%, which should look perceptually like a bright white, unless it is next to something even brighter. If you are getting speculars at 60%, something is going wrong!

Are you sure you are not tone-mapping twice? Because the ACES Output transforms include tone-mapping, the input to them should be an un-tone-mapped scene-referred HDR image.

What is the ‘ACES LUT’ there? I’m seeing whites at 81% in the ‘ACES LUT Only’ image, suggesting that the input to the LUT is limited to 1.0, or the LUT itself is clipping its input to 1.0.

The image is not mine, I don’t know how he did it but I get likeable results in my tests.
I’m testing with this, a white plaster bust and everything looks washed out. I know it shouldn’t look perfect but a bit more highlight roll-off without turning everything dark would be preferable. I’m testing with physical light strength in lumens and 1:1 scale. I can keep trying to push the image further, maybe making the plaster glossier, or raising the light, but I don’t expect great results.

I want to apply view looks in CDL so I don’t compromise the dynamic range, hence my question at the top, then preferable load the CDL in Resolve, keep grading and maybe add an artistic tonemapper.

Do you think it’s incorrect to apply a tonemapper even if I’m using ACES filmic ODT?

The image used had a Camera tonemapping within render (honoring the dynamic range). But here is without any tonemapping only raising the light strength.
It has a maximum brightness of 0.85 as luminance or about 215 in RGB. Over this it would further break the highlights.
sRGB%20ACES%20glossy tm8idyau9qytut9bg

Using a tone-mapper for aesthetic reasons in combination with ACES is valid. But none of your images when run through an inverse of the labelled Output Transform produce ACEScg values above 1.25. I would suggest something in your pipeline is limiting the dynamic range of the scene-referred image.

I will not comment further, as I should leave it to somebody more expert in CGI.


Yes, I also noticed that values don’t get any more white than that and assumed it was correct. Double checking the plaster color is 0.822 white which respects PBR for albedo as you mentioned before. Thanks for the help.

For comparison, this photographic image from an ALEXA (taken from a CML test) which includes a real plaster bust, contains ACES values going to about 5.0 in the highlight on the bust. Admittedly the bust is deliberately hard lit.

Note: image normalised so 18% grey chip is at ACES = [0.18, 0.18, 0.18]
and shown with Rec.709 ODT

And here is the same image shown with Utility - sRGB - Texture used instead of an Output Transform

If I input as albedo a white higher than 0.89* or so the highlights break, looks not physical plausible, although theoretically I could go as far as 0.94 PBR wise. The picker is “Output - Rec.709” though, looks like it reads the color_picking role, should I change it to ACEScg?

I couldn’t push higher than 2.50 in dynamic range at most. I’m rendering with Redshift which has limited ACES support (only for viewer, not nodes). So I will run more tests on Arnold. The photo reference was a good help to know where to aim.
I had to keep reflection weight to 0.822* otherwise it starts looking like metal, we know that reflection is always 1.0 physically but this is how CG works.

*Actually looks like when enabling OCIO or ACES all white color swatches default to 0.822 instead of 1.0


I’ve the same issue like this with arnold in maya with OCIO 1.0.3

Hello Jose L, substance aces filter this topic is closed.but I have some questions.
My Workflow is substance painter to maya(redshift with aces_1.0.3) ,I get LUT+filter on your gumroad below. in the substance paint,have a ‘white piont’ Value under the Color Profile Tabs.color_profile_ui Do I need to change it? If I use the HDR export for substance painter,Should I change HDR to ACEScg in nuke?