1 The idea
An ACES pipeline sets colour in three places: the input transform when a file is read (it says where the file came from), the working space where the maths happens (ACEScg), and the view/output transform for looking and delivering. In between, everything is linear ACEScg.
All three steps are wrong here. At the start the colour chart looks “fine”, because two mistakes cancel out. Fix the view and the chart suddenly over-saturates: that is the gamma-only texture trap.
2 Hands-on
Task: set all three steps so the picture matches the reference
Move the wipe to compare yours (left) with the reference (right)
3 Deep dive
The three places colour is set
Footage should be converted only twice: once on the way in to the working space and once on the way out per delivery. Everything in between stays in linear ACEScg, and looking at it on a screen is only a pair of glasses that doesn’t touch the data.
- 1Input transform (Read)
- 2ACEScg: comp
- 3View (Viewer)
- 4Output (Write)
Match the input transform to the file
Ask what the file is, not what you want it to look like. A render already in ACEScg is tagged ACEScg. A linear file with Rec.709 primaries needs a primaries change. An sRGB photo needs its curve removed and its primaries changed. Data maps such as normals or roughness must be Raw.
| File | Input transform |
|---|---|
| Render EXR already in ACEScg | ACEScg |
| Linear EXR, Rec.709 primaries | Linear Rec.709 (sRGB) |
| Colour PNG/JPEG | sRGB Texture |
| Camera log footage | That camera’s IDT |
| Normal, roughness, mask | Raw |
Mistakes that cancel out
At the start of this figure the chart only had its curve removed and the view only applied the sRGB curve. Both “forgot” the primaries, so the chart looked right. Switch the view to ACES 2.0 SDR (it converts AP1 → Rec.709 inside) and the chart over-saturates at once: the red patch 214, 38, 46 shows as 193, 0, 42 instead of 166, 25, 31. Real shows hit this too: everything looks fine until the correct config is switched on.
Fix the pipeline from the end (the view) first, then check each input one by one
Review files vs hand-off files
EXRs handed to other departments stay scene-linear, with no view transform baked in. Review files such as a MOV or JPEG get the output transform for the display they’ll be watched on. Everyone on the team must use the same config and ACES version, or nobody sees the same colours.
4 In real work
In Nuke
- Project Settings > Color: color management = OCIO, the team’s ACES config, working space = ACEScg.
- Read: set every input transform to what the file really is; always check what Nuke guessed.
- OCIOColorSpace: convert between spaces mid-graph when needed (into log and back, say).
- Viewer: pick the display/view for your monitor; the image values don’t change.
- Write: hand-off EXRs in ACEScg with no view; review MOVs with the display’s output transform.
- OCIODisplay: bakes a display/view into the branch that renders a review file.
Common mistakes → the fix
- ✗ A colour texture set to “gamma only”✓ Use sRGB Texture (curve + primaries).
- ✗ Reading a linear EXR as sRGB again✓ It goes dark and contrasty. Tag it linear with the primaries it was rendered in.
- ✗ Baking the view transform into a hand-off EXR✓ The next person applies the view again and the picture breaks. Always hand off scene-linear.
- ✗ Team members on different configs or ACES versions✓ Keep one show config in one place and point everyone at it.
Before you send the shot
- Every Read has a deliberately chosen input transform
- All data textures are Raw
- The Viewer uses the same display/view as the team
- Hand-off EXRs are scene-linear with no view baked in
- Review files carry the output transform for their display
5 Check yourself
A colour texture (albedo) saved as an sRGB PNG comes into an ACEScg comp. What does it need?
🔒 Answer the question above and this card opens
1. The comp looks right on your machine but different on a colleague’s. What do you check first?
2. Which input transform does a roughness map need?
Where the numbers come from: Colour maths comes from src/figures/colormath.ts (sRGB IEC 61966-2-1, ARRI LogC3 EI 800, sRGB/P3/Rec.2020/ACES AP1 primaries and Bradford, checked against reference numbers). The input and working-space conversions are real matrices (sRGB/Rec.709 → AP1 with Bradford D65 → ACES white) and match the ACES studio config v4.0.0 (Linear Rec.709 (sRGB) → ACEScg, and sRGB Encoded Rec.709 (sRGB), formerly Utility - sRGB - Texture). The view is real ACES 2.0 output via OCIO 2.6, studio config v4: sRGB - Display / ACES 2.0 - SDR 100 nits (Rec.709), baked into a 33³ LUT on an ACEScct grid (within about 0.02 of exact OCIO values on our test colours; the largest errors are in very bright saturated colours). The chart colours are our own; option names are shortened from what OCIO configs call them.