Gamma, Linear Light, and Transfer Functions

Transfer functions are not just curves on a chart. They decide how many code values shadows receive, how a blend behaves, how alpha edges composite, how much HDR luminance survives tone mapping, and where a renderer accidentally double-decodes or double-encodes a signal. This workbench lets you poke the whole pipeline at once.

Two unrelated facts collided in the 20th century to produce gamma encoding. First, the cathode-ray tubes that dominated displays for fifty years had a non-linear response: an input voltage V produced a screen luminance roughly proportional to V^2.2. A linear-in-voltage signal looked nothing like a linear-in-light scene. Second, human vision is also non-linear: we are far more sensitive to small differences in dark tones than to small differences in bright ones. A linear-light ramp from black to white spends most of its visual extent looking nearly white.

These two facts almost cancelled. Encoding light through a ≈1/2.2 power curve before sending it to a CRT produced the visually-uniform tones we wanted, and the CRT's own 2.2 response decoded it back to linear light. The "happy accident" became infrastructure. Even though CRTs are gone, every modern display still emulates that response, and every file format still stores values that have been raised to roughly the inverse power.

The eye's lightness response is approximately a cube root of luminance over a wide range - that's exactly the formula CIE L* uses to perceptually scale Y. A power function with exponent 1/2.2 approximates the cube root closely enough that a roughly perceptual encoding falls out automatically. Modern displays no longer have intrinsic gamma - LCDs are nearly linear; OLEDs are approximately so - but they still simulate the historic CRT response so files stay compatible.

The sRGB transfer function is the one almost every file you touch was encoded with. It approximates a γ ≈ 2.2 curve but with one important refinement: a small linear toe at the very dark end. Pure power curves have infinite slope at zero, which causes numerical instability in quantized arithmetic. The linear toe keeps the curve well-behaved near black.

Notice that the curve uses 1/2.4, not 1/2.2. The piecewise structure - linear toe + power segment - gives an effective exponent close to 2.2 over most of the range. Calling sRGB "gamma 2.2" is shorthand. The piecewise function is the specification; the 2.2 number is an approximation that fails in shadows.

Several transfer functions show up across modern imaging. Knowing which one your file uses is half the battle.

Two completely different things wear the same "RGB" badge. Encoded RGB is what files store - non-linear values shaped by a transfer function. Linear RGB is what physics deals in - values proportional to actual photon counts. Every reasonable color operation lives in one of these two spaces, and the conversion between them is the transfer function.

Take 50% red and 50% green at full encoded value: #ff0000 and #00ff00. Average them naively in their encoded form: you get #7f7f00, a dark mustard yellow. Average them in linear light, then re-encode: you get something close to #bcbc00, a bright olive yellow. The dark answer is physically wrong - it represents less light than either contributor.

This shows up everywhere. Gaussian blur, image resize, alpha blending, gradient interpolation, anti-aliasing, lighting math, color picker midpoints. Every operation that produces a value between two pixels must compute in linear space and re-encode. Almost every classical 2D graphics library got this wrong for decades; modern libraries are still partially broken.

Alpha compositing - putting a partially-transparent image over a background - has exactly the same linearity requirement as blending. The Porter-Duff over operator C_out = C_top · α + C_bg · (1 − α) is correct in linear light. Apply it to encoded values and you get the same too-dark midtones - typically visible as dark halos around the edges of anti-aliased text or premultiplied alpha images.

If you only have 8 bits per channel - 256 levels - you can either spread them evenly across linear light (which wastes most of them on the bright end where the eye can't distinguish neighbors) or spread them evenly across perceptual lightness (which puts more levels in the dark range where the eye is sensitive). Gamma encoding is exactly that re-allocation.

The full path from file to photon traverses several stages, each of which can introduce or undo a transfer function. Visualising the chain prevents most gamma bugs.

Traditional gamma assumes a fixed maximum: file value 1.0 = display white at some small fixed luminance, typically 100 cd/m². HDR breaks that assumption. HDR displays can show peaks of 1000-10 000 cd/m² and need transfer functions designed for that range.

Two HDR transfer functions dominate. PQ (Perceptual Quantizer, SMPTE ST 2084, used in HDR10 and Dolby Vision) maps file values 0-1 to absolute luminance 0-10 000 cd/m² using a curve based on the Barten contrast-sensitivity model. HLG (Hybrid Log-Gamma, used by BBC and NHK for broadcast HDR) is relative - its lower half is a standard gamma curve so legacy SDR receivers decode something usable, and the upper half is logarithmic to extend dynamic range.

Knowing the curve is one thing; spotting where a pipeline is missing it is another. The following bugs are everywhere.

Six questions on gamma, linear light, and transfer functions. Wrong answers come with brief explanations.