Care should be taken when transitioning scenes to Maya 2017+ from previous versions of Arnold for Maya as some fundamental changes have been made to the Color Management and .tx texture workflow. These changes are listed below. For further information, refer to the Arnold for Maya 2017 release notes.
Autodesk Color Management (also known as the Synergy color management component, or SynColor) is a shared technology component that is integrated into several Autodesk applications. This allows for consistent processing, interpretation, and communication of colors throughout a mixed pipeline. Autodesk Color Management is designed to support a variety of color management methodologies, including ACES, ICC, OpenColorIO, and ASC CDL. It allows you to work with different color spaces and encodings so that you can adopt new workflows or emulate legacy ones.
Autodesk Color Management consists of a color engine together with a collection of transformations suitable for input, output, display, and other situations. The transforms are provided as separate files in .ctf format, an extension of the Academy/ASC XML color transform format. You can combine multiple files to create complex transformations, and in addition, you can author your own files for custom purposes.
The color engine supports a wide variety of color operations, including 1D look-up tables (LUTs), 3D LUTs, gamma, log/antilog, exposure-contrast, matrix multiplication, and more.
In addition to native .ctf files, Autodesk Color Management can import many common color transform file formats, including the legacy Autodesk .lut and .3dl formats as well as third-party formats such Cinespace, Iridas, Pandora, and Nuke.
When OCIO is used in Maya's Color Management, a node color_manager_ocio is exported to avoid dependencies with SynColor.
Maya’s Color Management is now fully supported with Arnold in Maya 2017. The Display View Transform defined in Maya Preferences (Windows->Settings / Preferences-> Preferences) is now applied to all display devices (Arnold RenderView, Maya Render Viewer, Material Viewer, VP2). Previous versions of MtoA did not support color management of input textures (including gamma). Maya 2017 now supports color management with input textures by default. Therefore, you may notice a difference in the gamma of your renders between Maya 2016 and 2017.
You may run into issues related to color space in Maya 2017 if you open an existing scene (from Maya 2016 or earlier) where you did not consider color management.
By default, Maya's Color Management sets all textures to sRGB. However, most of the time EXR files are linear. The example below shows what happens when rendering an Ai Skydome light using an EXR file set to 'sRGB' (default) compared to using 'Raw'. The image on the left (sRGB) appears bright because the sRGB view transform is being applied twice.
- A way around this is to set a rule in Maya's Color Management so that all EXR files are set to 'Raw' color space.
Color Management rule added that converts input color space of 'EXR' images to 'Raw'
- Alternatively, you can set the color management manually for the HDR map connected to the Ai Skydome light.
HDR map's Color Space set to 'Raw'
For input textures, the Color management rules are applied when converting the textures to mipmaps (.TX files). The “Color Space” attribute also appears on the Arnold Image nodes and is taken into account during the TX conversion. An attribute “auto-tx” in the Arnold Render Settings is enabled by default. It automatically converts all the files to .tx mipmaps when necessary. This way the default behavior is now that Color Management is correct for both input textures and display. A progress bar will appear on the first render (or when a texture is modified) to show how many images are being converted to mipmaps. By disabling “auto-tx”, the textures will have to be converted manually : The TX Manager (Arnold->Utilities->TX Manager) now shows the color space for each texture, and converts each of them to the appropriate one. Deprecated “Gamma Correction” attributes from the Arnold Render Settings (Display Gamma, Shader Gamma, Texture Gamma, Light Gamma) were removed. The parameter texture_automip (similar to the new auto-tx but performed in RAM at every render) has been removed too.
The input color space and the rendering color space are now used by Maketx to color manage the texture just before the MIP-mapping. Care should be taken with this option as ALL textures in the scene will be converted to .tx and you may notice some differences in your renders. This may be apparent in scenes that contain normal maps, vector displacement maps and HDR maps used for lighting (color management is now supported by the Ai Skydome light and the Ai Sky shader in Maya 2017).
The output & input color space and the rendering color space are now used by kick to color manage the resulting image.
Things to consider when using .tx textures in Arnold for Maya 2017:
- Arnold, by default, understands that everything is linear.
- The File In node Color space is respected by Arnold, only if the texture is converted to .tx and 'Use Existing .tx textures' is set to ON in the Textures tab of the Render Settings.
- Textures can be automatically converted to .tx (see above).
- 'Use Existing .tx Textures' must be enabled to have properly color managed textures. You must use the latest version of MtoA's Maketx tool to convert all textures since they will be converted using an accurate color space (delete any old existing .tx files).
- If you disable 'Use Existing .tx Textures' and render JPEG files (for example), your render will be brighter since you are doubling the sRGB color transform. Arnold works linearly and therefore has no idea what the File In node will be at render time. If your JPEG is not linearized using a sRGB color space and you have your View transform set to sRGB it will equal twice the sRGB value.
'Auto-convert Textures to .tx' in Maya 2017 may overwrite any .tx files that had been previously saved in 2016. Maya 2016 will then render the new .tx file in a different color space and will appear incorrect.