C2 sRGB is not gamma 2.2 · Lab

1 The idea

Many people call sRGB "gamma 2.2". From mids to highlights the curves almost overlap, but sRGB has a short straight segment near black (below 0.0031308), so the shadows can differ by several code values.

Convert in with sRGB and out with gamma 2.2 (or the other way round) and the blacks float or sink. That is one source of "blacks don’t match between apps".

2 Hands-on

Switch to "darks 0 – 0.02" and hunt for the biggest gap

SkyVFX Lab · C2interactive · 1001

3 Deep dive

Inside the sRGB curve

sRGB has two pieces. Below 0.0031308 it is a straight line with slope 12.92; above that it is a 1/2.4 power scaled by 1.055 and shifted by −0.055. The decode side switches at 0.04045.

The straight piece stops the curve being infinitely steep at zero. A pure power curve is extremely steep near black, which amplifies tiny values like noise and makes the inverse unstable. So sRGB averages close to 2.2, but it is not 2.2.

Where the gap is

From mids to highlights the two stay within about 1.5 code values of each other. Deep in the shadows they split; the biggest gap, about 8.5 of 255, sits around linear 0.002 (the 0.002 row below).

Linear value	sRGB (of 255)	gamma 2.2 (of 255)
0.001	3.3	11.0
0.002	6.6	15.1
0.005	15.6	22.9
0.01	25.5	31.4
0.18	117.6	117.0

Rec.709 is a third curve

sRGB and Rec.709 share the same primaries and white point (D65); only the curve differs. Nuke’s “rec709” option is the camera-side encoding curve, while an HD display following BT.1886 decodes with roughly a 2.4 power.

So the same file will not look identical on an sRGB monitor and a Rec.709 TV. Ask where the client watches before you deliver.

Curve	Shape	Where you meet it
sRGB	linear toe + 1/2.4 power	textures, web, computer screens
gamma 2.2	pure power	some apps and older files
Rec.709 (camera)	its own toe + power	HD video encoding
BT.1886 (display)	about a 2.4 power	HD TVs and grading monitors

When it matters in a real shot

Night shots, dark smoke and the shadows under a CG robot are where this gap shows. Read with sRGB and write with gamma 2.2 and the blacks lift by several code values while the highlights barely move, so nobody notices until the grading suite.

1Read plate (sRGB)
2Write untouched (sRGB)
3Read the output back
4Merge difference = pure black

Do one round-trip test at the start of a show; it saves a lot of fixes later

4 In real work

In Nuke

With Nuke’s own colour management, sRGB, rec709 and Gamma2.2 are separate choices on both Read and Write. Pick the one the file was actually made with.
In OCIO configs the names depend on the config; some ACES configs use names like “Utility - sRGB - Texture”. Check the list in the show’s config.
Check the round trip with a Merge (operation: difference) between the source and the written file read back in.
Push the Viewer gain well up to make shadow differences visible.

Common mistakes → the fix

✗ Using sRGB and gamma 2.2 as if they were the same✓ Use the same curve in and out, or the shadows can shift by up to about 9 code values.
✗ Linearising with a Grade gamma instead of a colorspace✓ Use the Read colorspace or a colour-conversion node, so the curve is right and inverts exactly.
✗ Writing a web delivery as rec709 (or the reverse) without asking for the spec✓ Ask what screen it will be watched on and pick the matching curve.
✗ Blacks differ between apps, so you grade to fix it✓ Check each app’s transfer function first. Usually it is a setting, not a grade.

Before you send the shot

The plate’s Read and Write use the same named curve
Round-trip difference comes out pure black
The delivery curve matches the spec and the client’s screen
Dark shots checked in the shadows with high Viewer gain

5 Check yourself

One question to check yourself

Where do sRGB and gamma 2.2 differ the most?

What you learned

🔒 Answer the question above and this card opens