Color Management - OCIO ACES

Table Of Contents

• Introduction
• ACES vs Linear sRGB
• Visual Comparison
• ACES Concepts
• ACES Config Components
• Common OCIO color spaces and their purpose
• ACES Workflow
• Step 1: Redshift Color Management Setup
• Custom OCIO Config
• Step 2: Convert Assets to ACEScg
• Step 3: Rendering with ACES
• Unclamped vs Clamped Output
• Color Management Parameters

Introduction

ACES workflow	Linear sRGB workflow

Color management is an inherently complex subject, but the ultimate goal of a proper color management workflow is to simplify the process of color handling throughout a project. When working in Redshift there are many times that bring color directly into the equation, like when using a diffuse texture in a material or an HDRI image in a dome light, and color management helps ensure that those colors are displayed as intended.

Since Redshift version 3.0.46  OpenColorIO was implemented directly into Redshift. OpenColorIO (OCIO) is an open source color management system that allows users to easily manage their color throughout all stages of the production pipeline in a predictable and consistent way. Native OCIO support in Redshift leverages the use of the industry standard ACES color encoding system as the new default rendering color space in the form of ACEScg. 

Prior to the implementation of OCIO all rendering in Redshift was done entirely in scene-linear Rec.709 - sRGB color space and many artists utilized the "linear workflow" as part of their method for color management, when using ACES the workflow changes slightly but the general concept of color space consideration and linearizing your source assets before rendering remains largely the same. 

ACES vs Linear sRGB

The introduction of ACES as the default Redshift rendering color space brings with it many potential improvements compared to the old default rendering setup in scene-linear Rec.709-sRGB with an un-tone-mapped preview.

ACES has a much wider color gamut than sRGB making it capable of representing more colors and more accurately portraying scenes. Due to this increased dynamic range both highlights and shadows have more detail, with a smoother more filmic response and the ability to handle extreme lighting and color saturation. Colors in ACES desaturate as they become brighter in a similar way that we see with our eyes. In general, working with ACES provides an easier path to creating more predictable and photo-realistic images in less time and effort. On top of that, ACES aims to simplify working with formats from many different sources and color spaces with an easy to follow workflow from the start to finish of a production pipeline.

Before, when using scene-linear Rec.709-sRGB with a linear workflow, there was no distinction between linear color data ( a linearized diffuse color map) and linear non-color data (normal / roughness maps) but ACES is a color-aware workflow that needs to understand the differences between the two or else the result will be incorrect, this is primarily handled by designating the appropriate color space of the source assets as discussed here.

Visual Comparison

Below are some comparison images of a simple demo scene and various colored objects and two lights, the left light has a color temperature of 2000k and the right 13000k. The demo scene highlights several key things when comparing the new ACES versus the linear sRGB methods, with each set of comparison images the only thing that was changed was the intensity of the lights, all color values remain the same throughout. The example scene is not intended to serve as a demonstration of why one method is clearly superior to the other, but as a general example of some of the key benefits of how ACES handles challenging lighting situations and how it might improve your workflow.

Default ACEScg with ACES SDR-video view	Scene-Linear Rec.709-sRGB with Un-tone-mapped view

Straight away the ACES render looks more photographic and generally more realistic despite the uncanny scene. The lighting behaves more naturally in ACES, the bright lights hit the wall and the hottest parts of that light desaturate and roll off nicely back into the color of each wall. The old method begins to clip right away, the lights hit a maximum red and green value and just stay there completely blown out without any desaturation. This can also be seen on the top of the bunny model as well, in ACES the purely blue shader still maintains its shape under the warm 2000k light whereas the linear sRGB method essentially clips to blue and most of the detail is lost, particularly in the ear and face.

In general you might notice that the linear sRGB render looks brighter and by comparison feel that the ACES render looks dull in some respects. This is expected behavior with ACES as it attempts to maintain a more filmic look and in that regard things don't blow out in camera the way that we were used to when using the older linear sRGB method. For example, there are many objects in the real world that we consider having a white color but if we took a picture of them we wouldn't expect the resulting color value to be 1.0 - pure white. Instead, when under sufficient lighting, we expect those white objects to result in a lighter shade of grey relative to the other colors in the scene, it is only when things are over-exposed or bright sources of light are visible that a clipped output of pure white might be expected. ACES effectively works within that same level of expectation and so a scene-linear value of at least 16 is needed to result in a pure white (1.0) output value when mapped through sRGB.

Default ACEScg Exposure +2	Scene-Linear Rec.709-sRGB Exposure+2

In these examples we compare how an ACES workflow responds to increased exposure versus the linear sRGB method by increasing the light's exposure by 2. In general the ACES scene is holding together much better, despite clearly being over-exposed most surfaces retain a nice lighting falloff and the objects still have much more shape compared to linear sRGB which is quickly approaching an almost flat shaded look in spots. The ACES scene is much brighter now but most surfaces still aren't clipping to white and allow for more visual detail in the regions of shadow.

Default ACEScg Exposure -6	Scene-Linear Rec.709-sRGB Exposure -6

Going the other way, when we decrease the exposure drastically by 6 the ACES scene gets darker compared to linear sRGB which is partially due to the fact that the ACES sRGB output gamma curve is darker overall with the increased contrast of the more filmic look of ACES. However the linear sRGB example still demonstrates some of that color inconsistency in the visible warm light on the left side, the color of the light doesn't seem to correspond with the color of the light hitting the ground and grey ball while ACES holds onto a closer visual match between the two. 

ACES Concepts

The ACES workflow for CG in Redshift is designed to be relatively simple and artist friendly in practice despite the complex underlying color science that serves as its foundation: import and convert all assets to the same color space (ACEScg for Redshift), work in that unified color space, and when finished export everything to the format needed for the next stage in production. Working in ACES with Redshift already has many inherent benefits if your process stops at the render, it's easy to output tone mapped ACES SDR (standard dynamic range) sRGB images, but those benefits extend even further if you intend to apply further processing and effects afterwards in color grading and compositing. An ACES workflow in compositing continues much like it does in CG, importing and converting all assets to ACES, work in ACES, and exporting to the next format.

In order to facilitate moving through each stage of the workflow it is important to understand some of the key concepts that make up the ACES workflow and an ACES OCIO configuration file.

Color Management Terms	Description
Linear	Refers to a color space where the numerical value of a color and the actual perceived light intensity scales proportionally with each other. Linear color spaces are preferable for working spaces because the resulting values are more easily calculated and predictable; however as a display format a linear image is generally not considered visually appealing because human sight is non-linear so people tend to expect that type of look when determining if something looks "photo-realistic." Example: ACEScg is a linear color space
Non-Linear	Refers to a color space where the numerical value of a color and the actual perceived light intensity does not scale proportionally. Human vision is non-linear, we are more sensitive to value changes in darker colors than lighter colors. Example: Non-linear gamma curve in display sRGB.
Gamma	Defines the relationship between the numerical value of a color and its perceived light intensity. Example 1: Gamma 2.2 non-linear curve Example 2: Gamma 1.0 linear
Gamut	A gamut is the total set of all colors that are capable of being represented within a given color space. Example 1: ACES has an ultra wide gamut that is capable of representing more colors than sRGB Example 2: Rec.709 and sRGB have the same color gamut, they are both capable of displaying the same colors though they have different gamma curves.
Color Space	Refers to a specific gamut of colors with a specific gamma curve. Example 1: ACEScg is a linear color space with an ultra wide gamut. Example 2: sRGB is a non-linear color space with a narrow gamut.
Scene-Linear / Scene-Referred	This refers to the result computed by Redshift as raw linear data before any further kind of processing is done to the image. In situations outside of CG, this would refer to the direct result of the camera sensor recording light values as they are before processing. Example: The raw lighting data is being directly referred from the scene in a linear fashion.
Display-Referred	This refers to the converted output of scene-linear data into non-linear data in order to be properly displayed on a monitor in a specific color space. Example: Scene-linear result then converted to look correct on an sRGB monitor.

ACES Config Components

OCIO Config	This is the .ocio file that contains all of the relevant OCIO / ACES components needed for your OCIO color management workflow. It houses all your IDTs, ODTs and everything you need to get from the start to the end of your project within an ACES workflow. The same OCIO config should be used for all parts of the production pipeline when working with ACES, if you start your project in Redshift with one OCIO config the same one should be used when compositing with ACES in order to ensure consistency throughout the project. It's entirely possible to use different OCIO config files but care should be taken when doing so. This file is most commonly seen named config.ocio
ACES Color Space	Description
ACES2065-1	The foundation of ACES, a linear color space with the widest gamut of all ACES color spaces, capable of encompassing all the colors of human vision. ACES2065-1 is used for archival or transfer purposes rather than a working color space.
ACEScg	A linear color space used in CG and effects composting, default used by Redshift for rendering. Wide gamut.
ACEScc / ACEScct	Non-linear color spaces used for color correction. ACES cct has a different gamma curve in the form of a "toe" in the dark portion of the image compared to ACES cc. The resulting effect is footage that is more similar to grading in log.
ACES Transforms	Description
IDT - Input Device Transform	These transforms are used to take the color data of a specified source and convert it into a specified color space. In Redshift this is most commonly used when converting textures used in shaders and lights to the rendering color space. Example: Convert non-linear sRGB diffuse texture into linearized ACES color space
RRT - Reference Rendering Transform	The RRT converts raw scene-linear data into linear HDR display-referred data in preparation to be used with an ODT. This is a step that is performed automatically in the background whenever an ODT is used and is necessary to convert from the raw linear output into a color space suitable for conversion into the final display space for monitors.
ODT - Output Display Transform	These transforms are used to convert the high dynamic range RRT result into data that can be properly viewed on your display. Example: Convert linear Redshift renders / composites in ACEScg to display sRGB for final output/preview.

Common OCIO color spaces and their purpose

OCIO v2 Naming (Redshift default config)	OCIO v1 Naming (ACES 1.2 config)	Purpose
sRGB	Utility - sRGB - Texture	To be used on Input with LDR (low dynamic range) sRGB color images like JPEG and PNG.
Scene-Linear Rec.709-sRGB	Utility - Linear - sRGB	To be used on Input with HDR (high dynamic range) color images like dome light / area light textures and other linear HDR color images.
ACEScg	ACES - ACEScg	To be used on Input for pre-converted ACEScg textures.
Raw	Utility - Raw	To be used on Input with non-color (data) images like bump, normals, roughness, displacement etc.
Invert ACES 1.0 SDR-video	Output - sRGB	Can be used on Input to more easily match branding colors. This is known as using an inverted LUT as it involves using a transform normally reserved for Output as an Input. This is not recommended to be used with textures in a physically correct shader as things like pure white will be mapped unrealistically bright.
Camera Specific Color Spaces	Input - *Camera* - *Color Space*	To be used on Input with the matching camera specific color space.

ACES Workflow

Step 1: Redshift Color Management Setup

Before working in ACES an OpenColorIO configuration file must be set in the Color Management section of the Redshift Globals render settings. By default Redshift is set up to use the OCIO file path established by your computer's environment variable, if no OCIO environment variable is established then Redshift will default to the custom OCIO ACES configuration that Redshift ships with. This custom Redshift ACES config is pared down and it contains commonly used input and render color spaces (including ACEScg), as well as some output display transforms. Once an OCIO configuration file is properly specified a rendering color space can be chosen, ACEScg by default. 

After the rendering color space is specified you must select a display transform that matches the display you are working on to properly preview the renders. If you are using an sRGB monitor then you would use the default sRGB display transform. In addition a View transform can be selected to tone map the render to your liking, by default Redshift uses the ACES 1.0 SDR-video view transform which has some nice filmic tone mapping.

Redshift ships preconfigured for the most common ACES workflow but if yours is not setup try using the following settings:

Custom OCIO Config

If you would like to use your own custom OCIO config instead it's as simple as changing the OCIO configuration path in the Redshift Color Management settings to your own config file.

The OCIO config that comes with Redshift is lightweight, if you have the need for more IDTs and ODTs you can download the latest  ACES config file released here, save it somewhere on your hard drive and then set its location as the OCIO config path in Redshift or set its path in your own environment variable.

Step 2: Convert Assets to ACEScg

In order for colors to display as expected all source assets must first be converted into the same linear rendering color space, ACEScg by default. This is accomplished by setting the color space correctly for each asset using the color space drop-down menus pictured in the pictures above. These color space parameters serve as a built-in Input Display Transform (IDT) when viewed through the lens of an ACES workflow, the same general mentality as working with ACES renders in composite as described on this page.

Redshift automatically converts native color swatches like diffuse colors, ramp colors, and the Redshift physical sky into the linear rendering color space. Redshift is set up by default to  automatically convert any textures used with materials, lights, and dome lights into the rendering color space but there is a chance that it will get this automatic conversion wrong. It's important to make sure that the color space is set correctly for each asset which is why it can be overridden manually by following these  general tips:

• If your asset is for color data
• Examples: diffuse / albedo color, specular/reflection color, dome light texture/backplate
1. If you already know what the correct color space is set it to that
2. If it's a JPG / PNG / BMP etc set it to sRGB
3. If it's an EXR / HDR etc set it to scene-linear Rec.709-sRGB or other appropriate scene-linear color space

• If your asset is for non-color data
• Examples: normal, roughness, metalness, displacement etc.
1. If you already know what the correct color space is set it to that
2. Otherwise set it to Raw

Correct Color Spaces	Incorrect Color Spaces

In the example images above the only difference in scene setup is that the color spaces were set up correctly versus incorrectly. The diffuse color texture was set to raw instead of sRGB and all non-color textures were set to " sRGB" instead of the correct color space " Raw." Setting the color spaces correctly is required in order for renders to look right, in general incorrect color spaces for non-color textures negatively impacts the final result more so than incorrect color spaces for color textures. For example, the result of the normal map in the incorrect example looks fully broken, resulting in jagged unnatural reflections that fall far from achieving the correct result on the glass and in the bottom left of the lantern. Incorrect color spaces for color data like diffuse color and HDRI dome light backplate are more subjective, while still technically incorrect they don't visually break as drastically. For example, notice that the HDRI in the background becomes too saturated when incorrectly set to color space " raw" instead of " scene-linear Rec.709-sRGB," this is because it is being incorrectly transformed into the too wide gamut of ACES2065 vs the proper sRGB gamut that the HDRI was originally captured in.

Step 3: Rendering with ACES

Rendering with ACES is automatic when your scene is set up for OCIO ACES Color Management. If you intend to continue with compositing and editing of your ACES Redshift renders then you probably want to retain the ability to fully utilize the strengths of the ACES workflow in your compositor of choice in which case you would want to render out unclamped linear 16bit OpenEXRs. If that extra range is not necessary you can render out as JPG, PNG or other LDR (low dynamic range) file formats with the ACES View tone mapping baked in which will result in highlights being clamped to 1.0, limiting how far you can push edits in post as demonstrated with the comparison below. 

Multi-Pass Output Rendering

If rendering out with "Multi-Pass Image" use the same settings for "Regular Image" rendering above and you must also enable "32 bits" for the Bits Per Channel option in the AOV's Multi-Pass section even if the output EXR is set to only 16 Bit/Channel depth.

Multi-Pass Output 32 Bits Per Channel required for unclamped Multi-Pass Output

Direct Output Rendering

If rendering out EXR's via "Direct Output" the resulting files will correctly render out unclamped even if a tone mapping View transform is enabled, making it a safer export method less prone to human error and accidentally ending up with clamped EXRs.

Example settings for unclamped 16 bit Direct Output

Unclamped vs Clamped Output

Linear ACEScg OpenEXR with Output sRGB ODT - unclamped & unedited	Non-Linear sRGB JPG with Baked in ACES SDR View - clamped & unedited

At first without any editing both images look identical, as they should, but once you start editing the image the limitations of the clamped SDR JPG becomes readily apparent.

Linear ACEScg OpenEXR with Output sRGB ODT - unclamped & Gain +2	Non-Linear sRGB JPG with Baked in ACES SDR View - clamped & Gain +2

By increasing the gain the clamped JPG with the baked in view transform severely clips throughout the image while the unclamped image handles the over exposure very well as it is still benefiting from the flexibility and increased range of the linear EXR within the ACES workflow. This lack of range is exacerbated even worse if we take this image and go down with the gain adjustment.

Linear ACEScg OpenEXR with Output sRGB ODT - unclamped & Gain 0.3	Non-Linear sRGB JPG with Baked in ACES SDR View - clamped & Gain 0.3

When we reduce the gain from the default 1.0 to 0.3 the difference is stark, since the JPG version already had all of its highlights clipped to 1 everything is forced to reduce in brightness in a very uniform way. This is despite the fact that in the actual scene the Redshift lights are much much brighter than the walls that they are casting on, so the clamped image looks more like you are adjusting the opacity of a black solid layer on top of the image rather than adjusting the brightness of the scene itself as in the results of the unclamped EXR example. The raw value of the visible lights in the unclamped linear EXR go as high as 30 (compared to the clamped JPG's 1) so when the gain is reduced the picture darkens in a more predictable and realistic manner due to this much higher dynamic range.

Linear ACEScg OpenEXR with Output sRGB ODT - unclamped & Gain 0.02	Non-Linear sRGB JPG with Baked in ACES SDR View - clamped & Gain 0.02

We can take that to an even further extreme to demonstrate just how much more flexibility and range rendering out an unclamped EXR gets you with a gain value of 0.02. The clamped non-linear JPG is essentially completely gone at this point, and depending on your monitor calibration / viewing situation you may not even be able to see anything at all, but the unclamped linear EXR still looks great. It's certainly now a very dim and underexposed scene but it still looks appropriate and correct if this is the sort of look you're going for and it is easily achievable. 

Color Management Parameters

OpenColorIO Configuration

This sets the path to the OpenColorIO config file. By default Redshift ships with and uses its own predefined configuration but a custom OCIO config be set here as well.

Rendering Color Space

This is the linear color space that Redshift renders in, ACEScg by default which allows Redshift to make full use of its wider rendering color gamut. 

Display

This is the Output Display Transform that should be set to a color space that is supported by the display that you are working on, for most people this will be sRGB.

View

This determines how the image is displayed on screen and works in conjunction with the Display transform. By default this can be set to an ACES SDR tone-mapped result, un-tone-mapped, a logarithmic color space (ACEScct) or the raw linear result which is unaffected by the Display transform.

View: ACES 1.0 SDR-Video	Un-tone-mapped	Log	Raw

Use OpenColorIO File Rules

When enabled this will use any file rules established within the currently used OCIO config file. OCIO file rules are used to automatically set the correct color space for assets that fall within established parameters.

Examples:

• If a file is a jpg / png and has the words "albedo" or "diffuse" in the file name use the sRGB color space
• If a file is a jpg / png and has the words "roughness" or "normal" in the file name then use the Raw color space.