Hello,
I wanted to share a couple of tips for using ACES in some softwares.
Maya and ACES
The Color Management Module from Maya is pretty much explicit. You can access it in the settings/preferences.
If you load the ACES 1.2 OCIO configuration, you will get some presets that work well. Solid Angle has done a pretty decent tutorial on describing the ACES integration in Maya.
If you are using SynColor, Maya assumes an sRGB display by default. Although it is possible to use any of the other ACES display options by editing the synColorConfig file (please see the user guide).
Guerilla Render and ACES
Since Guerilla 2.1 (available for free) OCIO management is fully supported with looks and input LUTs, color picker and color boxes. All the roles are based on the OCIO config.
There is no need to use a .bat file anymore to load an OCIO Config.
And if you want to, you can still use a MaterialOverride node in your Render Graph to override the Input Device Transform (IDT) for the Color inputs.
Nuke and ACES
ACES has been integrated natively in Nuke since version 10. Nuke 12 integrates the ACES 1.1 OCIO config by default and the Foundry has even removed the spi-anim config ! Just press “S” to access the Project Settings → Color.
For final delivery of your project to the Digital Intermediate, you will have to deliver ACES compliant EXR files. This is the standard set by the Academy to exchange files between facilities. This is really important. Your output of 3D render will be ACEScg (AP1) but your output of Nuke has to be ACES2065-1 (AP0) with the correct metadata.
The interchange and archival files should be written as OpenEXRs conforming to SMPTE 2065-4. In Nuke, you should set the Write node’s colorspace to ACES2065-1 and check the box write ACES compliant EXR to get the correct metadata.
Resolve and ACES
All ACES transforms have been implemented in Resolve with CTL for better accuracy. I am not a frequent Resolve user but I have tried to come up with a few screenshots to setup Resolve in ACES.
Resolve is available for free which is awesome. You can access the Project Settings by right-clicking on your Project.
Or going to File → Project Settings… What is important here is that your render looks the same in Guerilla, Nuke and Resolve.
This is how to setup Resolve in ACES. Colorists have a personal preference for grading on ACEScct as it behaves more like a traditional log curve (if I understood correctly).
Some schools and studios have a final grading pass before delivery. This stage is called Digital Intermediate (DI) and is often done in Resolve. You may notice some visual improvements (with extreme values) if you have worked with OCIO during the whole process except this Resolve stage.
Some posts on the forum of Blackmagic also explain this setup and how to work between Fusion and Resolve.
Substance Designer
On December 2019, announcement has been made about Substance Designer supporting OCIO Color Management.
Mari
Liam Collod did a pretty good job on documenting Mari workflow. Here is another link as well.
Octane
Octane supports OCIO, since version 2020.2 (and for the curious, the current closed-private-beta is on OCIO 2.0).
Non-OCIO softwares
Unfortunately some softwares have not fully implemented OCIO yet : Redshift, 3dsMax… So what should you do if you cannot specify ACEScg as a rendering space in your favorite DCC ? Here is a quick workaround we have come with.
- Do a conversion of the textures to ACEScg.
- Load them as linear.
- Look at the render through an ACES ODT.
One may think : if I do that, the software would still render in “linear” but with the textures converted to ACEScg. Well, not exactly : if you do that, you are rendering in ACEScg. Instead of the IDT doing the conversion, you just did it yourself manually.
The IDT is just a faster way to work. In an OCIO friendly environment, you set the IDT on the texture and it converts automatically to the Rendering space (ACEScg in this case). BUT since you converted the textures manually, you are doing the exact same process. It is just longer. When Redshift or 3dsMax will integrate OCIO, you will no longer need to convert the textures.
There is a post on the vray forum that explains it better than me. 
If you don’t mind the complexity, you can right now pre-convert your textures to ACEScg using e.g. OpenImageIO’s oiiotool and then set them to use “ACEScg” colour space in Maya, which will default to linear colour space for V-Ray. Since we won’t be doing any colour conversions you’ll be effectively rendering in ACEScg colour space.
Agreed, by doing that, som features such as SunSky or Kelvin temperatures may not be color-managed properly.
Manual Conversion
There are several ways to convert manually your textures (I haven’t tested them all myself and if you have used different techniques, let me know) :
- Using Image Colorspace Converter.
- In Nuke, using an OCIOColorSpace node.
- Using OpenImageIo’s oiiotool.
- Using this online conversion tool.
- In Affinity.
- Using a custom transform node in Redshift.
- In Photoshop with the OCIO plugin.
- In Houdini with the batch converter in TOP network made by Dominik Lingenover.
- Using a command line (like maketx as shown below).
Here is an example of an Arnold command line to convert HDRIs (you’ll need maketx to make it work) :
"C:\Program Files\Autodesk\Arnold\maya2020\bin\maketx.exe" -v -u --stats --envlatl --colorconfig %OCIO% --colorconvert "Utility - Linear - sRGB" "ACES - ACEScg" "path\to\*.hdr" -o "path\to\*.tx"
%OCIO here is the system variable set to the OCIO config file. If you haven’t set it yet, just use the path to the config.ocio instead.
At last but not least, which textures should you convert ? You don’t need to convert grayscale linear maps (aka data maps) such as roughness or displacement maps. They will look exactly the same in “linear” and “ACEScg”. You may only convert color maps such as base color (albedo) or emission.
Redshift
Gamma is set to 1 like a linear transfer function. No primaries are declared which is “fine” for ACEScg.
You have access to the ACES ODTs in the View transform menu. Not as difficult as it seemed, right ?
There was was an IDT development task in their roadmap last I checked.
Substance Painter and ACES
UPDATE : Substance Painter 7.4 has been released with OCIOv2. Here are the links to the release notes :
Substance Painter is not OCIO friendly yet. But there is a workaround available to paint with an ACES ODT.
Substance Painter uses a Color Profile (exr) as a display LUT. This Color Profile must contain the transfer function adapted to your display device. Basically this display LUT for Substance Painter is a 2D texture. Its generation is documented on Allegorithmic website.
If you are not familiar with this method you can also generate the texture in Nuke by using the image reference provided by Allegorithmic. You just need to apply a colorspace transform from Utility - Linear -sRGB → Output - Rec.709 using an OCIOColorSpace node. The method is detailed in the following images :
You need to set Nuke in an ACES environment. Then load the reference exr in Nuke.
By default the exr will be interpreted as ACEScg.
This is the complete setup. Pretty simple, right ?
The OCIOColorSpace node converts from Utility - Linear - sRGRB to Output - Rec.709.
You can write the exr with these options.
Here is another method that may be even simpler. Set Nuke in ACES and load the reference exr.
Here is the trick : load it with the IDT Utility - Linear - sRGB.
Here is the complete setup. No OCIOColorSpace with this method. Less is more.
Write the exr with the following setting : Output - Rec.709. You’re done !
In the slide above, I detail two methods that will give the exact same result. I just wanted to show you both ways. Thomas Mansencal provides the Nuke nodes in this post.
By following this workflow, you should a pretty reasonable ACES look in Substance Painter. But there is one downside, highlights will be clamped because of the lack of log shaper pre-lut.
So a more accurate Nuke setup is described in this post. Which may look like this :
But because the log curve used in Substance Painter is undocumented, Jed Smith has to tried to reverse-engineer it and is available here as a spi1d.lut. Which will make the Nuke setup actually look like this :
For the record, the log curve comes from YEBIS and here is their answer when I asked about it :
One of the tone map curves provided by YEBIS, which is a YEBIS original function, is based on a logarithmic function. This is the most gentle curve in the YEBIS tone map, and has a low contrast. Therefore, it is easy to express a wide range of brightness. However, it’s not a very good curve from an artwork perspective.
Photoshop and ACES
ACES and Photoshop are giving headaches to many people and I wanted to describe a logarithmic workaround we have used for a couple of years now. I understand it is not as Photoshop friendly as an ICC profile but I know it would be helpful to some artists and students. We will start this workflow in Nuke and then move to Photoshop.
ACES uses two logarithmic color spaces : ACEScc and ACEScct. If you want to know more about the differences between them, just follow the link.
Photoshop can load a csp LUT as a display LUT layer. This display LUT must contain the transfer function adapted to your display device. Artists generally paint their Matte-Paintings in logarithmic in Photoshop and use a csp LUT to display the image correctly. Here is a description of this workaround method :
First, we will set Nuke in ACES.
Let’s read an ACEScg render in Nuke. You can either force the color space (ACEScg in this case) or use the role from the ACES config.
Let’s write it as a 16 bits tiff in ACEScc. It could be ACEScct, based on your preferences.
We can read our output to make sure it matches our initial render.
We can now open this tif file in Photoshop. I recommend a recent version of Photoshop like CC because we had some issues with CS6. The image looks grayish which is normal since its transfer function is now logarithmic.
We can now create a Colour Lookup Layer in Photoshop to load a csp file. This csp file needs to be based on your Display Transform. In our case, it is Rec.709 (ACES). But it could be P3-D60 (ACES) or sRGB (ACES) for example. Please remember this is only for display.
Thanks to the csp file the tif now matches what we had in Nuke but within a 0-1 range which is perfect to paint in Photoshop.
You can finally save a 16bit tif from Photoshop AFTER disabling the Colour Lookup Layer and go back to Nuke.
I know it is not a perfect ACES workflow but I think it is an easy workaround for artists who are not familiar with ICC profiles like myself. You can simply generate the csp display LUT in Nuke thanks to three nodes CMSTestPattern, OCIOColorSpace and GenerateLut. Here are some screenshots to show you how :
First set Nuke to ACES and then create a CMSTestPattern.
Do not hesitate to use at least 128 to get a better precision in your csp lut.
Here is the complete setup. Not too complicated, right ?
Set your OCIOColorSpace to ACES - ACEScc (the logarithmic space from ACES) to Output - Rec.709 which is our display LUT (ODT).
And finally you can write the csp file with the following options. Done !
I really want to state that this is only a workaround and you could probably check Affinity as well, which has a better ACES integration. If you’re looking at other ACES workflows with Photoshop, check this post.
Daniel Brylka recently added a Photoshop & ACES section to his website.
If you want to know about Affinity, Clarisse, c4d or Houdini, please check the links provided.
Hope it helps a bit,
Chris
