Hello everyone,
I have a question about ACES in Maya against ACES using an Ocio config.
I love the way this render looks using the ACES RRT V1.0 directly in Maya’s viewport.
This is a pure green plane (0/1/0) with a pure red sphere (1/0/0) with a white area light.
I think in this case ACES handles really well saturation and overexposure, better than
any tonemap.
Does anyone know which ctf file maya loads? Is it automatically loaded based on your screen colorspace?
Unfortunately I am not able to reproduce this nice saturated look in Nuke or any other software.
The Ocio Config 1.0.3 gives me this result:
I have tried to use the Nuke CTL module for Nuke but could not make it work. (https://github.com/JGoldstone/CTL/tree/nukeNode)
I have also tried to use the RRT+ODT nodes from Alex Fry but could not get a similar result. (https://github.com/alexfry/PureNukeACES)
Is the Maya ACES RRT V1.0 much different than any Ocio config? Are they compatible? Maybe I should ask directly Autodesk…
Any help or thought would be much appreciated!
Thanks in advance, Chris
The ACES OCIO config has some known errors, especially at bright values, that would explain the results you’re seeing. As a result (and as you discovered), in addition to OCIO, Maya also provides a rigorous implementation (using the CTF files) that gives a match to the official ACES CTL code. (This is also used in Flame, Lustre, etc.)
By default, Maya assumes an sRGB display although it is possible to use any of the other ACES display options by editing the synColorConfig file (please see the user guide).
At the present time you won’t be able to apply those CTF files used in Maya in other (non Autodesk) software, however you may be interested to hear that there is a potential solution for that on the horizon.
Autodesk is currently in the process of contributing the technology used in Maya for applying ACES transforms (and some other cool stuff) to OpenColorIO. This initiative, called OpenColorIO v2, is far from complete at this point, but we demo’d some good progress at the OCIO Birds of a Feather meetup at SIGGRAPH last week.
In the meantime, anything that allows you to apply the exact math of the official ACES CTL code should match what you’re getting in Maya.
The issue you’re seeing isn’t due to potential inaccuracies in the OCIO configuration. The default working space when using Maya’s native color management is ‘scene-linear Rec 709/sRGB’. When you switch to using the ACES OCIO config, the working space switching to ‘ACES - ACEScg’, with no other option available in the ‘Rendering Space’ drop down menu. This is unfortunate…
If you open the rendered image from your project’s images/tmp folder in Nuke with the ACES 1.0.3 config chosen in Settings, you can reproduce the issue easily. Read the image in twice, once with ‘ACES - ACEScg’ selected as the colorspace and a second time with ‘Utility - sRGB - Texture’ as the colorspace. You’ll see the same problems.
If you choose ‘ACEScg’ as the working space when using Maya’s native color management, you should see something very similar to what you get when you switch to using the ACES OCIO config and can only use ACEScg as the working space.
The Rec 709 and ACEScg primaries are pretty different, so it’s not surprising that they produce different results.
It would be great if the Maya OCIO implementation didn’t have the limitation of only using ACEScg as the working space.
Following up on HP’s reply, there are a number of settings that can lead to color differences between applications and HP is right to point out that the choice of rendering or working space is certainly one of them and I would not be surprised if that is indeed the case here. (I am on vacation this week and am unable to verify it myself.) That said, there have been other threads here in the past where it was actually the Output Transforms in the ACES config that were the problem.
If you want to change the rendering/working color space in Maya, you just need to set the “rendering” role in the config to your desired space. If the config doesn’t set the rendering role, you should actually get a drop-down menu with the ability to choose one within the app. Here is some relevant documentation from the user guide: http://help.autodesk.com/view/MAYAUL/2017/ENU/?guid=GUID-4AE9AABC-A900-4276-AFE4-F9DCD96BA03D
Regarding beta testing OCIO v2, this can be done but currently requires some software engineering expertise. You would need to download and compile the source code from the OCIO master branch on github at which point you could use tools such as ocioconvert to process images. We hope to make this easier as we get farther along. The upgraded ACES transforms are not submitted yet, but there is some other good stuff such as a new GPU renderer.
Hello Doug and HP,
a BIG thank you to both of you! I had been doing some tests for the past three weeks and I could not make it work like I wanted.
My mistake was pretty obvious:
I was in ‘scene-linear Rec709/sRGB’ in Maya but loading my exr in Nuke as ‘Acescg’.
I switched to ‘Utility-Linear-sRGB’ in my read node and it matched!
There is still a tiny difference but it could be due to the difference CTF/OCIO.
Anyway, thanks a lot for your help!
That was very very helpful!
Thanks for getting back to us Chris with your findings. They do make sense. The Maya viewport is a bit of a torture test for ACES Output Transform implementations as it is easy to create lighting ratios and colors that would rarely occur in real world photography. However, aside from these edge cases the ACES OCIO config does do a nice job so no surprise that it was a working/rendering space issue. Glad to hear the mystery got solved!
It has a tendency to go towards purple… Red and green seem to react better.
But as we would never put such an extreme value in our textures, that’s not a concern I guess.
Thanks everyone!
When use ACES via OCIO in maya ,the color picker is not work as before any more, it alway pick color with nagative value and high V value, is it correct?
How could i pick the color from an preference picture and rendering it corrcetly?
that’s very weird. I never had the issue before. This is what the color picker should look like:
Are you using the latest official ACES 1.0.3 config?
It includes a role for color picking and I never had issues with it before.
Which version of Maya are you using?
I didn’t use texture,just a shader with simple color here.
yes,every setting is right and is working well when use textures.
The problem is when switch to ACES use ocio, its quite easy get some over saturate or over bright color ，cause some V value of the color cant over maybe 0.82？ otherwise the color look like “emission” Is this behavior correct when switch to ACES ? and do you have this problem?
And how can it preserve the color when i use color piker in maya and aces?
sorry I was on holidays.
I have loaded the texture into Maya using ACES 1.0.3, picked some values from it and did not get any negative value.
Can you send the .ma file? Where do you pick these negative values from? A render?
In terms of albedo values, yes, we are not supposed to go over approximately 0.8. Thomas Mansencal has posted an albedo chart on the forum in a post. I can find it back for you if you need.
thanks for the sharing. I have been able to reproduce the bug.
If I am not mistaken, it only happens when you open the BaseColor window
from the Hypershade (double-click on the color slot in the Hypershade).
I have to say that I never use this particular window.
If I map a plane in Emission with your texture and render it, I do not have the issue.
I may have found a better solution for this particular window.
If you click in the texture without using the color picker, you will
not get the negative values ! Pretty cool, right ?
I’ve tried, it still have that issues, and if you pick the color this way,you can see that color is not match from where you pick when render.
What i want is maintain the srgb color in aces system.
