Making OpenColorIO Work for You (Patreon)

When working on a CG project across many different apps one major challenge is making sure colors display consistently. Will your Arnold render look the same in After Effects as it does in Maya? What about in Nuke, Photoshop, or Resolve?

The free, open source OpenColorIO (OCIO) color management solution aims to solve this problem. Using it ensures that colors will always look the same no matter which app you're using or what display you're viewing on. People generally use OCIO in conjunction with the Academy Color Encoding System (ACES), which provides a broad range of color profiles to work with every type of monitor, projector, camera, and file format.

In this article I'll cover the general concepts of OCIO/ACES, explain how to edit an OCIO config file to suit your workflow, and provide real-world examples. Let's roll!

Why OCIO and ACES?

When you use a color management system you guarantee that images look the same in all apps and on all displays and behave in predictable ways. This gives you the freedom to focus on things that really matter instead of wasting time wondering "why does my render look dark and weird here when it looked fine there?"

What is OCIO? For our purposes it's a set of rules that assign color spaces to specific roles. Apps access these rules via a config file (often just called config.ocio) and use them to color manage input and output images and display devices.

The process is broken down essentially into 3 phases:

1. What color space should be used for incoming images?2. What color space should rendering/compositing/other calculations be done in?3. What color space should be used for outgoing images?

OCIO lets us define these roles and customize them to our liking.

ACES provides the math to be applied to each role. OCIO can tell us that a JPG from the internet should be assigned the sRGB - Texture role and ACES can define what sRGB - Texture is, mathematically. ACES includes a large set of predefined color spaces and LUTs to work with just about any possible image, input device or output device.

Here's an illustration of how OCIO and ACES interact to provide a complete color management system:

OCIO: I've got a video file from a Canon camera here. What should I do?

ACES: Here's the manufacturer's color profile for that camera and the math you need to display and convert it.

OCIO: Here's another job for you: the user wants to display these PNG images on an HDR monitor.

ACES: Easy, I've got the PNG input transform and monitor output transform math right here.

Config Files: What They Are and How to Make Them

Any OCIO/ACES color management system hinges on a single plain-text configuration file. Usually these are just called "config.ocio" but they can be named anything. I stick with the .ocio syntax at least, even though it's not strictly necessary.

To get started understanding how this all works, let's download an ACES config: https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases/download/v1.0.0/cg-config-v1.0.0_aces-v1.3_ocio-v2.1.ocio

This is the latest and greatest Academy Software Foundation release using OCIO version 2 and ACES version 1.3. This particular config is designed to be used for CG work. As such, all the hardware camera definitions from standard ACES have been removed. A compositor would need a different config as they'll be working with footage from many different cameras and will need access to those roles. In our case, the CG config is just fine and will make it easier to understand what's going on.

After downloading the config, put it into a place of your choosing and then point your system OCIO variable to it. This is a quick and easy way to ensure that all your apps are on the same page; they all automatically look for an OCIO system variable. On Windows the variable declaration would look something like this:

You could stop right here and use this config as-is, but this wouldn't be a Brian article without exhaustive detail. Let's dive in to explore how these config files are made. This will allow you to customize everything to your exact needs. Have an HDR monitor? Build your config around that. Use keywords in your Substance Painter texture file names like "albedo" or "roughness"? Add that to your config. It's a powerful system and surprisingly easy to use with just a little practice.

I'll cover general concepts here and explain what will be useful to customize and what to ignore. For a full breakdown of what everything does, read the official docs here: https://opencolorio.readthedocs.io/en/latest/guides/authoring/overview.html

Header

The config header includes the OCIO version number, config name, description and a few other attributes: environment, search_path, strictparsing and luma. These latter four can be ignored in our case as they are either optional or only relevant for advanced usage. You can change the name and description as desired.

Roles

The roles section is key and includes many required definitions that all apps look for. You should keep this core set of named roles no matter what, although you can assign different color spaces to them. For example, you should always have a scene_linear role, but you could assign Linear Rec.709 (sRGB) to it instead of ACEScg.

Where this gets more powerful is allowing you to create custom roles. This is great for making artist-friendly configs. For example, you could create a role called exr_16_bit and set it to ACEScg. Then users would easily know at a glance which role to use for 16-bit EXR images.

Rules

Another great feature of OCIO is the ability to set file rules. Many apps (though not all) will check these rules and auto-apply them for you. For example, I like to tag texture files with their role in material assignment, such as texture.color.1001.exr for base color, texture.disp.1001.exr for displacement, etc. In this case, I added two sample rules to assign the color spaces I want:

These rules are applied to EXR files that include "color" or "disp" in the file name, assigning either ACEScg or Raw color spaces. The Default rule is required.

Shared Views

This section is optional and is a convenience feature to allow you to define general-purpose view transforms. For example, in the AWSF CG config there is an "Un-tone-mapped" entry that can be applied to any display to remove its default tone-mapping. Here, the "Un-tone-mapped" view is defined once and reused in all the display definitions.

Displays

This section defines the color management for your monitoring hardware. A general purpose config usually includes many different hardware options: computer monitors, TVs, projectors, etc. If you're creating a config for a specific setup then you can simply remove the inapplicable displays. I personally don't need Rec.2020 or P3, so out they go!

You can also remove colorspaces, displays and views from in-app lists using the active_views, active_displays and inactive_colorspaces attributes. This can help with readability as there are many colorspaces that you will never need to access, such as CIE-XYZ-D65. Or, if you don't need P3 displays, instead of deleting them entirely you could remove them from the active_displays list. Taking these steps will keep all your OCIO/ACES menus in various apps clear and easy to understand.

All the Rest

The rest of this config consists of ACES mathematical definitions of all applicable colorspaces. You are free to remove unused ones and add new ones sourced from other configs. Creating new ones requires sophisticated knowledge of color science and math so it's best to leave the existing ones as-is and only add ones that are confirmed to be correct and fully functional.

For my custom config I added transforms that "bake" sRGB or Rec.709 into the image. This is useful if you want to quickly output JPGs or PNGs from OCIO-enabled apps that will display correctly on standard Windows image viewers, phones, etc. If you need to save a baked image from Nuke you would simply set the colorspace in the Write node to sRGB SDR as defined here:

I had to consult with some experts to make sure this works as intended. If you want to do something similar, feel free to ask at the ACES Central forums.

Closing words

Congrats! You should now have a thorough understanding of the general ideas behind OCIO/ACES color management and how to customize the system to your unique requirements.

My fully customized config is available here: https://github.com/BrianHanke/bhgc_v2.ocio/releases It's a further simplification of the ASWF CG config and I use it every single day. You can embrace it as-is or use it as a guide for building your own.

While this all might initially seem a bit confusing, it's well worth adopting the system so you have full control over how images behave throughout your creative pipeline. Fortunately, OCIO is almost universal these days and all major apps have robust support for it. Once you get it set up you're good to go and won't have to think about it again!