Color Management Overview – Help | OTOY

Octane Overview | ~1,188 words, 6 min read

About This Guide

This is part of a conceptual, DCC-agnostic series on how OctaneRender works. This guide tries to keep color management tolerable for a beginner.

Intro and Overview

Color management is probably one of the biggest challenges that we have going right now in the graphics and display technology world. It's widely misunderstood and misrepresented, and there's a lot of heat behind discussions about it. It's a necessary evil though - if we don't line the settings up right, we're going to have a bad time.

There's an entire set of Octane Guides dedicated to it that try to tell the story in a number of ways in varying levels of detail. This guide is more about awareness than anything, and as such, shall be presented as a neat, bulleted list for your summarized reading pleasure:

Color

Radiation exists across a broad spectrum of wavelengths.
Our eyes and brains register a very narrow band of those wavelengths which appear to us as visible light. We interpret the different wavelengths in this band as different colors. We call this the "visible spectrum".
We are also only sensitive to a certain range of intensities of this radiation (what we generally called "luminance" if we want to be technical, or "brightness" if we don't.)
Our brains are biased toward certain colors and certain intensities of light, which is useful to know for later when we talk about tone mapping.

Color Data

OctaneRender works with a massive amount of color data. Most of that data can't be reproduced by current (or likely even future) display technologies. It needs to do this so that the physical light calculations it uses are as accurate as possible - even if we can't display the source data. Light calcs still affect everything down the line and determine what we eventually can display.
When the engine is done rendering, it can save all of that original color data to a file (an EXR or TIFF) that also can't be fully displayed on any current technology. This is needed so that we have as much flexibility as possible when we work with these files in post and don't lose any important data.
Once we are done editing and processing the large set, it's usually compressed down and saved as a smaller set (JPEG, PNG, or some type of stream) that contains just enough data to cater to and look good on the class of devices we're targeting. This is done because the smaller set can be stored and distributed a lot more efficiently than the large set. When it's time to consume the data, there's no sense wasting massive amounts of storage and bandwidth to send stuff the device can't even show.
The large set (source files) is usually kept around in case we need to go back and further modify it, or produce a different smaller set for a different device.

Color Spaces

The big hunk of source data is set up in one of a few standardized ways called "working color spaces" that allow several different editor apps (DaVinci, Nuke, Fusion, After Effects, etc.) to understand and edit it while keeping the original intent of the render.
The smaller, tailored data sets are set up in one of a few standardized ways called "display color spaces" that allow a variety of target devices to interpret them correctly (computer monitors, cinema projectors, HDTV, etc.).
If a file using a display color space is put in an editor and pushed too far (colors or luminance values shifted), the lack of extra data means the image will start to blow out or cause other artifacts like in the illustration above.
Working color spaces are for working, display color spaces are for displaying.

Color Space Conversion

Data can be transferred easily and mostly accurately between working color spaces (ACEScg, Linear sRGB, etc.).
Most of the time, data can not be transferred well between display color spaces (sRGB, DCI P3, Display P3, Rec.2020). This is because different data is lost during the conversion to each of these spaces from the original source, so they don't map nicely to each other.
OctaneRender is a spectral engine (it works with light spectra). This allows it to play nicely with any working color space. If it's just you doing solo work, use the one that the DCC is happiest with (current trend is ACEScg, but Linear sRGB is perfectly fine too). If you're part of a team, use the one the rest of the people or apps in your pipeline are using.

Tone Mapping

Part of taking the large set and trimming it to the small set is a process widely referred to as "tone mapping". All the values in the large set can't be saved, so different methods have been devised to determine which values are lost. All of these methods cater to our brains' preferences for different wavelengths and luminance values (why show stuff we can't see or differentiate very well?)
There are two ways to compress a big set of color data into a smaller set:

We can just lop off the values that don't directly map to the small set (no tone mapping). This does the best job of keeping the original intent of the colors that do survive, but the hard cut means there might be harsh artifacts (usually highlight clipping) if our lights are too hot or certain material values are too extreme.
We can shift colors around to make a smoother transition, but at the expense of them staying true to the original intent. Some methods like ACES RRT+ODT create a more contrasty "cinematic" look and shift colors pretty severely to produce this. Others like Octane's "smooth" or AgX are a bit more uniform in their approach, but we often need to further process them to get closer to the intended look. None of these other methods will perfectly preserve the originally picked RGB values, but unless we're doing exact brand color matching, it's more the final look that matters anyway.

If a scene is kept to plausible (and low-ish) values, no tone mapping becomes a viable option and does the best job of preserving the original chosen colors.
If a scene uses high intensity values (even if they're technically plausible), one of the other tone mapping methods will be needed to prevent blowing out colors and causing other problems. In this case, we'll need to choose between the available options, all which produce different looks.

Wrap Up

So, that's it in a nutshell. This is seriously going to take a lot of reading, research, and running into the same issues a few times before it sinks in for good. It's not you, it's the system. On to greener pastures - Post and AOVs!

Author's Notes

This guide originally appeared on https://contextualguides.com and https://help.otoy.com/hc/en-us/categories/201718003-OctaneRender-Support-Guides

Articles in this section