Short answer
A transfer function is the curve that converts between stored numbers and physical light. Colour spaces compress light non-linearly — 'gamma encoding' — because human vision is far more sensitive to differences between dark tones than between bright ones, so a curve spends more of the available codes on shadows. The curves differ because each was designed for a different viewing situation: sRGB for an office screen, BT.1886's 2.4 for a dim video suite, PQ for absolute HDR brightness, HLG for HDR that still works on SDR sets.
If an 8-bit channel stored light linearly, the step from code 1 to code 2 would double the light — a huge visible jump in the shadows — while the top hundred codes would describe highlight differences no one can see. Perceived lightness is closer to a cube root or a logarithm of light than to light itself, so a power-law encoding with an exponent around 1/2.2 spreads codes roughly evenly by perception. That is the whole purpose of gamma today: efficient use of a limited number of bits. The historical coincidence that CRT displays had a similar power-law response made the scheme cheap to implement, but modern panels are driven by electronics that apply whatever curve the standard asks for.
sRGB uses a piecewise curve that approximates 2.2; Display P3 borrows it unchanged. Adobe RGB uses a pure power of 563/256 (about 2.199). ProPhoto RGB uses 1.8, a legacy of early Macintosh publishing. Television is split into two curves: BT.709 defines how cameras encode (a linear toe of slope 4.5, then a 0.45 power with offset) and BT.1886 defines how reference displays decode (essentially 2.4). HDR adds two curves from BT.2100: PQ, which maps code values to absolute luminance up to 10,000 cd/m², and HLG, a relative curve whose lower half is gamma-like and upper half logarithmic. The table on this page shows how differently the same half-scale signal is rendered.
Because encoded values are not proportional to light, maths done on them gives physically wrong answers. Averaging red (255, 0, 0) and green (0, 255, 0) as numbers gives (128, 128, 0), a dark olive, whereas mixing the two lights gives a much brighter yellow. The same error darkens edges when images are scaled, muddies blurs, makes anti-aliased text look thinner or bolder than intended, and skews alpha compositing. Correct pipelines decode to linear light, compute, then re-encode. CSS offers srgb-linear and display-p3-linear spaces for this, and CSS Color 5's color-mix() defaults to OKLab, which models perception rather than light and is usually the better choice for visual blends.
Physically correct (linear-light) mixing and perceptually even mixing are different goals. Linear light predicts what overlapping lamps do; OKLab predicts what looks half-way.
The classic transfer-function bugs come from a pipeline that loses track of whether values are encoded. Applying the decode twice makes images too dark and contrasty; skipping it makes them pale and flat. Treating video's camera curve (BT.709 OETF) as the display curve lifts the shadows. Mixing curves between tools — for example, a game engine writing linear values into an 8-bit texture marked as sRGB — causes banding in dark gradients. The cure is always the same: tag every buffer and file with its transfer function, and convert explicitly at each boundary rather than assuming.
| Encoding | Curve | Defined in | Light at 50% signal |
|---|---|---|---|
| sRGB (and Display P3) | Piecewise: linear toe, then 2.4 power with offset | IEC 61966-2-1 | 21.4% |
| Pure power 2.2 | Single exponent; what many displays actually apply | Common display practice | 21.8% |
| Adobe RGB (1998) | Pure power 563/256 (≈ 2.199) | Adobe RGB (1998) encoding | 21.8% |
| BT.1886 (HD/SDR video display) | Power 2.4 (with zero black level) | ITU-R BT.1886 | 18.9% |
| ProPhoto RGB | Power 1.8 with a small linear toe | ROMM RGB, via CSS Color 4 | 28.7% |
Why: Interpolation in gamma-encoded sRGB, the legacy default for CSS gradients.
Fix: Specify an interpolation space, for example linear-gradient(in oklab, …).
Why: Linear-light values stored in an 8-bit buffer without sRGB encoding.
Fix: Store 8-bit buffers sRGB-encoded (or use higher bit depth for linear data).
Why: The camera OETF was inverted as if it were the display curve.
Fix: Decode using the BT.1886 display response for SDR video.
Each statement is labelled by kind — established fact, a standard’s requirement, observed market data, a convention, or Colourwise’s own interpretation or analysis — with the strength of the evidence behind it.
StandardStrong evidence
BT.709 specifies the camera opto-electronic transfer function (a linear segment of slope 4.5 near black, then a 0.45 power with offset), while BT.1886 separately specifies the reference display's 2.4-power response.
Source: ITU-R Recommendations BT.709, BT.2020 and BT.2100; Recommendation ITU-R BT.1886: Reference electro-optical transfer function for flat panel displays used in HDTV studio production
StandardStrong evidence
ITU-R BT.2100 specifies two HDR transfer functions, PQ (perceptual quantisation, as in SMPTE ST 2084) and HLG (hybrid log-gamma), in place of the conventional SDR gamma curve.
Source: ITU-R Recommendations BT.709, BT.2020 and BT.2100; Report ITU-R BT.2408: Guidance for operational practices in HDR television production
StandardStrong evidence
CSS Color 4 defines linear-light variants of sRGB and Display P3 (srgb-linear, display-p3-linear), and CSS Color 5's color-mix() interpolates in OKLab when no space is specified.
Caveat: CSS Color 5 is a working draft; defaults could change before it is finalised.
Colourwise analysisStrong evidence
A half-scale signal produces about 21–22% of full light under the sRGB curve, Adobe RGB and a 2.2 power, but about 19% under BT.1886's 2.4 and about 29% under ProPhoto RGB's 1.8.
Based on: Computed by Colourwise from each published transfer function; see the table on this page.
Source: CSS Color Module Level 4; Recommendation ITU-R BT.1886: Reference electro-optical transfer function for flat panel displays used in HDTV studio production; Adobe RGB (1998) color image encoding
Reviewed 29 September 2026. Colourwise summarises its sources in its own words and does not reproduce standards text or proprietary colour data. Spotted an error? Tell us.