Since Maya 2022, Autodesk has included Open Color IO v2 as standard with the install. With these config files it’s possible to setup many renderers to use ACEScg. ACEScg, or the Academy Color Encoding System cg space, is a wide gamut colorspace that can be used for rendering. The wide gamut allows the renderer to work with and produce more lifelike color values. The VRay docs elaborate on its useage: VRay ACEScg
The color primaries for ACEScg are much closer to the end of the visible spectrum. By color primaries, I’m referring to the RGB values, indicated by the points on the triangle. These new primaries are referred to as AP1. As a result, ACES is a wide enough gamut that can easily encapsulate the Rec. 2020 and DCI P3 colorspaces, which are HDR compliant, in addition to the sRGB colorspace.
ACEScg colorspace is much closer to achieving 100% coverage of the visible light spectrum than sRGB
Configuring Maya and VRay for ACEScg.
There are a few things we need to do to implement ACEScg. First, we need to set Maya to use ACEScg by default for it’s rendering color space. We can edit this in the Preferences dialog under the Color Management category.
Here I set Rendering Space to ACEScg, Display to sRGB, and View to ACES 1.0 SDR-video. Note that I’m also setting the OCIO Config Path to the correct config.ocio file which comes with Maya 2024.
The ACES 1.0 SDR-video is a color transform that will allow us to view the extended dynamic range of ACES in a way that can be easily displayed on a standard sRGB monitor. A majority of consumer monitors cover at least 95% of the sRGB colorspace, and in many cases 100% or more. In my experience, it’s best to stick with sRGB calibration, even if your monitor supports DCI P3 or wider gamut working spaces. Many current Apple products support DCI P3 color. But if your end use case is posting content to the web, it’s generally better to set things up to target sRGB as the final output.
In addition to setting up Color Management in our settings, we also need to setup the VRay framebuffer to display correctly.
In this low quality test render(I get impatient sometimes), the Input colorspace is set to raw, and the View transform is also raw. This is incorrect.
In this test render, I switched the VRay framebuffer to load the OpenColorIO config. Notice the more natural looking color(despite the pixelation)
The above images illustrate the results when loading the wrong colorspace in the VRay framebuffer, vs setting it correctly. In the first image you can see the contrast levels are incorrect - the image appears to have the wrong gamma curve applied, and has a purple color shift. By comparison, in the second image we see more natural blue colors that reflect the tones in the HDR image used in the VRay Dome Light. Here I’ve set the View Transform to be ACES 1.0 SDR-video. Note that I have Save In Image checked on. This will ensure that the image we save is encoded in the correct color space when we save it from the frame buffer to an EXR file to include all our channels.
The third place where we need to be mindful of our colorspace settings is on the file node in Maya. Whenever we load a texture file, we need to ensure that the correct colorspace is set. For HDRIs, this should generally be raw format when working in ACEScg. Input color textures will need to be encoded with ACEScg color settings, even if they’re .jpg or .png(which are typically sRGB space). For data maps, such as bump, displacement, and maps driving glossiness/roughness, these should generally be raw. Below I’ll detail how we can use Nuke to easily encode our images in ACEScg format for texture color maps.
OCIO in Nuke
Larger studios have more complex setups, and often times a dedicated team that manages color and LUT configuration for a studio, in addition to monitor calibration and calibration of the projectors used in dailies to ensure consistency.
For us lowly home users, sRGB is simplest as mentioned. But there are a few key things we need to do to configure Nuke correctly. In our file Project Settings, we need to set Nuke to use Open Color IO. The benefit of the Open Color IO standard is consistent display across a variety of apps, and that includes Nuke.
Much like Maya, we need to tell Nuke to use the Open Color IO config, set the working space to ACEScg, and the display color space to the correct sRGB transform.
We also need to configure our Read nodes correctly. Because we baked our SDR transform into our images, we need to tell the Read nodes in Nuke to load an sRGB LUT.
The Input Transform for this EXR should be set to matte_paint, sRGB.
Now that we have OpenColorIO setup in Nuke, we can also use Nuke to write out ACEScg encoded files. The image texture may display in sRGB, but this will allow VRay and other renderers to use our color maps correctly in the full wide gamut ACEScg space.
We can change the output transform on our Write node, which will automatically handle the conversion.
This image is incorrect. Here I’m loading a standard srgb image map while rendering in ACEScg space. Notice that the reds are very saturated, and borderline clipping, almost turning magenta.
This render uses a texture that was encoded in ACEScg space. It’s still technically an 8 bit sRGB image, but can now be read in correctly by the renderer. The colors here are more subdued and natural. In particular, look at the ‘Pop’ font on screen right. It has much less red bleed.
Above, I show two test images to illustrate the difference between ACEScg images and sRGB. In the first image, the texture for the soda can is encoded as sRGB. This produces noticeable clamping in the color, as sRGB is not wide enough gamut to work in ACEScg space. In the second image, I converted the image to ACEScg format using a transform in the Write node. The second render has the file node input set to ACEScg, which is supported by the data in the image. As a result, the colors look much more natural.
This image was rendered using the standard Scene Linear to sRGB workflow in Maya
This image was rendered in ACEScg. Note the more accurate color - the blue is much closer to sky blue and in general the image feels richer.
The above images further highlight difference between ACEScg vs standard workflows. In the first image I’m rendering in Scene Linear space, then converting to sRGB. In the second image I’m rendering in ACEScg, with an sRGB viewing LUT in the VRay framebuffer. The ACEScg image has much more natural color - it correctly capture the sky blue color in the HDR I’m using - and has better definition and contrast.
ACES has many benefits - primarily color consistency, more lifelike colors, and higher dynamic range. Hopefully this helps you implement it in your renders in the future.