Color, From Light to Pixels!

Color management is invisible when it’s right and obvious when it’s wrong, but most of the time it’s wrong in ways that are almost invisible - a slightly-too-warm sky, a black that isn’t quite black, a green that’s been poisoned in conversion. This page is about the system I reach for to keep that from happening. It’s called ACES, and once you understand it, you can’t unsee it.

Before we can talk about ACES, we have to talk about light.

Light is physical. Pixels are not.

A real-world scene has effectively unlimited dynamic range. The sun is millions of times brighter than a shadow. A camera sensor counts photons (more or less), and the numbers it produces are linear with respect to light: twice the photons, twice the value.

A monitor emits light in a different way, and human vision perceives that light non-linearly. Somewhere between the sensor and your eyeball, those linear photon counts have to become the right pixel values for your monitor. That somewhere is the color pipeline.

The four transforms

Every shot goes through (at least) four transforms:

1. Camera encoding. The camera squeezes its high dynamic range into a compact format (Log3G10 for RED, Log-C for ARRI, etc.).

2. Working space conversion. That camera format gets converted to a wide-gamut linear space for VFX work.

3. Grade space conversion. For grading, we move from linear to a log-encoded space that’s intuitive to artists.

4. Output transform. Finally, everything gets compressed and shaped to fit a Rec.709 monitor or an sRGB browser.

Why each transform exists

The camera transform exists because the sensor’s full range can’t fit in a normal file format without compression. The working-space transform exists because all light-based math needs to happen in linear values. The grade transform exists because grading curves only behave the way artists expect when stops of light are evenly spaced. And the output transform exists because a Rec.709 monitor cannot show what’s in the working file - it has to be told what to show.

Each of those steps has rules. To follow them, you need to know what a color space actually is - not the marketing version, the working version.

A color space is a set of rules that maps numbers to colors. Three components define it: a gamut (which colors can be represented), a transfer function (how brightness is encoded), and a white point (what counts as neutral).

Gamut, primaries, and the horseshoe

The CIE 1931 horseshoe is the map of all colors humans can see. A gamut is a triangle on that map - the corners are the red, green, and blue primaries of the color space. Inside the triangle, you can mix the primaries to make any color. Outside the triangle, your color space simply can’t represent it.

Notice what happens when you turn on ACES2065-1: the triangle extends outside the horseshoe. That’s not a bug. AP0

• the primaries used by ACES2065-1 - was chosen to contain every visible color, including ones that don’t physically exist. This makes it useless for daily work and perfect for archival.

ACEScg, by contrast, uses AP1 primaries that fit just inside the visible spectrum. Wide enough to handle anything a real camera can capture, narrow enough to behave well in math. This is why we render in ACEScg, not AP0.

Transfer function (gamma)

The eye doesn’t see light linearly. Doubling the photons doesn’t double the perceived brightness. Display systems and image formats take advantage of this with a transfer function - a curve that allocates more code values to dark tones (where we’re sensitive) and fewer to bright tones (where we’re not). The curve has a name in shorthand: gamma. A gamma of 1.0 is linear. A gamma of 2.2 is the rough perceptual curve used by sRGB.

Drag the slider to 1.0 - that’s linear, no curve. Drag it to 2.2 - sRGB. Drag it to 2.4 - Rec.709 broadcast. Notice how the gradient bar’s midtones get darker as gamma increases, even though the math is just output = input^(1/gamma). That’s the entire concept. Everything else is engineering details around that curve.

White point

The third leg of the stool. The white point is the chromaticity that a color space considers neutral - what counts as “white”. D65 (≈6500 K) dominates web and broadcast because it approximates average daylight. Cinema uses DCI white, slightly green of D65, for projector standardization. ACES uses D60. Mismatched white points produce subtle casts in supposedly neutral areas - gray cards drift, skin tones shift. It’s the kind of error you can stare at for an hour without naming.

So a color space is a triangle (gamut), a curve (transfer function), and a reference white. Once you have those three, you have everything. Now let’s talk about why we use different color spaces for different stages of the pipeline.

Linear is for math

Light behaves linearly. Two lights at brightness 0.5 add up to brightness 1.0. Glows, motion blur, depth of field, exposure adjustments - these all need real-light math. If you do them on gamma-encoded values, the math is wrong, and you get the kinds of artifacts everyone has seen but few have named: glows that look anemic, blurs that smear toward white, exposure changes that crush shadows wrong.

Log is for grading

The problem with linear: it allocates almost all its bit budget to a tiny range of bright values, because the dynamic range of a real scene runs from ~0.001 to ~1000+ in scene-linear units. Log spaces redistribute that range so each stop of light gets roughly equal precision. That makes grading intuitive: when you push the shadow region of a curve, the curve actually moves the shadow region. In linear, the shadow region is squeezed into the bottom 1% of your data and curves are unworkable.

The top histogram shows linear bit allocation. Look at where midgray (0.18) lands - it’s only 18% of the way up the chart, but visually it’s the center of a normal exposure. Now look at the bottom histogram, which is ACEScct (log). Midgray is at code value 0.413, and the stops are evenly spaced. If you’re pulling a grade with curves and lift/gamma/gain controls, log is what you want under your hands.

So we use both

Comp in ACEScg (linear). Grade in ACEScct (log). Convert between them losslessly via OCIO. Each space is doing the job it’s good at. The conversion is not lossy, not creative - it’s just a different encoding of the same scene.

Bit allocation matters in another way too: how many total bits you have to spend.

What bit depth actually buys you

• 8 bits per channel: 256 values. Fine for delivery, terrible for working.
• 10 bits: 1024 values. Better. Standard for video.
• 16-bit float: enormous range, including values above 1.0 (highlights brighter than white). Standard for VFX.

The gamma test

Drag the gamma slider. At γ = 1.0 the three look identical - every bit is used evenly across the ramp. Push past γ = 2.2 (sRGB display) and the 8-bit version starts showing visible stair-steps in the shadows. By γ = 3.0 the bands are unmistakable in 8-bit; 10-bit is starting to show. The float version stays smooth, because there’s effectively no quantization to expose.

This is why we work in 16-bit float EXR for VFX. Not because we need the precision today, but because we don’t know what we’re going to do to the image tomorrow. Future-you will push that gradient through three more curves and a defocus, and 8-bit you would have a banded mess.

Now we have the pieces. Let’s see how they fit together end-to-end.

Camera → working → grading → delivery. Five color spaces, five conversions, no surprises if everything is set up correctly. Click any stage to see what happens at that stage in detail.

Conversions are reversible (mostly)

Every conversion in this chain is mathematically defined and reversible. ACEScg ↔ ACEScct is a clean round-trip. Log3G10 → ACEScg is clean. ACES2065-1 → ACEScg → ACES2065-1 is clean.

Where you lose data: at the ODT, by design. The ODT is creatively compressing your wide-gamut, high-dynamic-range work into something a Rec.709 monitor can show. That’s a one-way process for any single delivery, but the master in ACEScg is preserved

• re-master to HDR later without re-rendering anything.

Speaking of the ODT - let’s see what one actually does to an image.

What you’ve never been seeing

Every image in Nuke, Resolve, After Effects (when configured correctly), and any OCIO-aware viewer is being shown to you through a viewing transform. You’ve never seen the raw scene-referred values. They would look terrible.

The reveal

The left side is the raw scene-referred ACEScg values, displayed as if they were sRGB - milky, low-contrast, washed out. The right side is the same data through the Rec.709 ODT - punchy, saturated, normal-looking.

The right side is what you’ve been calling “the image” your whole career. The left side is what’s actually in the file. The ODT is the function that turns one into the other, and it does it on the fly, every time you look at your viewport.

Why this matters

• The ODT does not affect your render or export (unless you bake it in intentionally). It’s a viewing-only operation.

• Different ODTs exist for different displays: Rec.709, sRGB, DCI-P3 cinema, Rec.2020 HDR.

• If you grade or composite while looking through the wrong ODT, your work will look wrong on the right one.

The ODT is one source of “looks wrong” errors. Let’s look at the others.

Almost everyone has shipped at least one of these errors. They’re the failure modes that come from pipeline mistakes, asset mismanagement, or just being in the wrong color space at the wrong moment. The good news is that once you’ve seen the type of error, you can recognize it forever.

Patterns to internalize

• Crushed shadows + saturated highlights → color space mismatch on input.
• Washed-out, low-contrast everything → ODT missing or wrong.
• Banded gradients → bit depth too low, or color space conversion routed through 8-bit.
• Color casts on neutrals → white point mismatch.
• Highlights that go magenta → out-of-gamut handling failure.

If you remember nothing else from this page, remember the rules.

If you’ve made it this far, you’ve got the concepts. Here are the rules.

The “Print this card” button strips everything else and prints just the card. Pin it. Share it.