1 The idea
In comp a pixel value is an "amount of light" (scene-linear): twice the light, twice the number. Eyes do not see light linearly, so the screen needs the sRGB curve to convert the numbers before showing them.
Mid grey at 18% (linear 0.18) lands around 0.46 on screen, because the curve lifts the darks. Slide to see how far the number and what you see differ.
sRGB = 12.92·x (x ≤ 0.0031308), 1.055·x^(1/2.4) − 0.0552 Hands-on
What looks like "half" on screen is not 0.5 in linear
3 Deep dive
Two kinds of numbers: scene-linear and display-referred
Scene-linear numbers follow the light in the scene. An 18% grey card sits at 0.18, and a lamp or a sun glint can go well past 1. There is no ceiling.
Display-referred numbers are already shaped for a screen: a JPEG, a PNG, a graded MOV. Here 1 means “the brightest the screen can show”, not an amount of light.
| scene-linear | display-referred | |
|---|---|---|
| The number means | Amount of light | Brightness on a screen |
| Range | 0 to far above 1 (float) | 0–1 (usually clipped) |
| Typical files | CG EXRs, linearised plates | JPEG, PNG, review MOV |
| Safe for light maths? | Yes | No, convert first |
Why comp maths needs linear
Merge, blur, defocus and motion blur all add or average light. They are only right when the numbers really are amounts of light.
Example: imagine a car parked in the desert plate. A sun glint on its window reads about 20, next to sand at about 0.12. Defocus it in linear and you get a bright, clean bokeh disc. Do it on display values and the glint is capped at 1, so the disc comes out dull grey.
- 1Read: convert to linear
- 2Comp maths (merge, blur)
- 3Viewer: display curve
- 4Write: encode to spec
Reading the numbers you sample
The Viewer shows the image through the display curve, but the values you sample are linear. A pixel that looks “half grey” on an sRGB screen samples at about 0.214, not 0.5.
| Linear value | On screen (sRGB) | vs mid grey |
|---|---|---|
| 0.045 | 0.235 | −2 stops |
| 0.09 | 0.332 | −1 stop |
| 0.18 | 0.461 | mid grey |
| 0.36 | 0.634 | +1 stop |
| 0.72 | 0.865 | +2 stops |
Remember one pair: linear 0.18 shows as 0.46
Conversions happen only at the edges
Footage should be converted once on the way in (Read) and once on the way out per deliverable (Write). Everything in between stays linear. Looking at it is the Viewer’s job, not a node in the graph.
Nuke works internally in 32-bit float whatever the source bit depth, so values above 1 survive the graph unless a node clamps them.
4 In real work
In Nuke
- Read: set colorspace to what the file really is (sRGB for a JPEG, linear for a CG EXR). Under OCIO the Read converts it into the working space, primaries included when the config defines them (an ACES config, for example). With Nuke’s own colour management it only linearises the curve and leaves the primaries alone (see C5).
- Project Settings > Color: choose the colour management (Nuke or OCIO) and the working space. That decides what “linear” means for the whole script.
- Viewer: the display/view menu changes only what you see; sampled pixel values stay linear.
- Write: set colorspace to the delivery spec. Same setting on Read and Write gives a round trip with no shift.
Common mistakes → the fix
- ✗ Adding a linear→sRGB Colorspace mid-graph “to see better”, then merging after it✓ Let the Viewer do the display. Values in the comp stay linear all the way.
- ✗ Seeing 0.18 and deciding the CG is too dark✓ 0.18 is mid grey; on screen it shows around 0.46. Judge through the Viewer and against the plate.
- ✗ Clamping everything at 1 because “1 is white”✓ Values above 1 are real light, and glows, defocus and motion blur need them. Clamp only for a clear reason, such as before building a mask.
- ✗ Reading a CG EXR as sRGB✓ Render EXRs are usually linear already. Decoding them again makes them darker and over-contrasty. (An extra display encode does the opposite: washed out and lifted, see C6.) Use what the pipeline specifies.
Before you send the shot
- Every Read has a deliberate, correct colorspace, not just the default
- No display conversions left in the middle of the graph
- If a correctly exposed grey card is in shot, it samples near 0.18; far off means a wrong colorspace or exposure
- Values above 1 survive all the way to the Write
- Write colorspace matches the delivery spec
5 Check yourself
To double the light in comp, what do you do to the linear value?
🔒 Answer the question above and this card opens
1. A pixel samples at 0.214 but looks exactly half grey on screen. Which is true?
2. A defocused sun glint in the desert plate turns into a dull grey disc instead of a bright one. Most likely cause?
Where the numbers come from: Curves and matrices are computed from published definitions (sRGB IEC 61966-2-1, ARRI LogC3 EI 800, Rec.709/P3/Rec.2020/ACES AP1 primaries) and checked against published reference numbers. The tone curve is an example formula, not ACES/AgX/Filmic.