Gamma / EOTF Curve Comparator

What an EOTF actually does

An EOTF (electro-optical transfer function) is the display's half of a video signal's contract: it takes a normalized code value from 0 to 1 and says how much light comes off the screen. The camera or grading side has the inverse job — an OETF (opto-electronic transfer function) turns scene light into signal on the way in. sRGB, gamma 2.2 and gamma 2.4 are EOTFs by convention (an SDR display literally raises the incoming signal to a power). PQ (SMPTE ST 2084) is also specified as an EOTF, directly in absolute nits. HLG (ITU-R BT.2100) is unusual: it's defined as an inverse OETF — signal back to normalized scene light — with a separate OOTF (opto-optical transfer function) doing the display-referred conversion afterward. That distinction is why this comparator plots HLG's inverse-OETF curve rather than a true EOTF, flagged below.

sRGB vs. gamma 2.2: close, not identical

The persistent claim that "sRGB is just gamma 2.2" is off by design, not by rounding error. sRGB (IEC 61966-2-1) is a piecewise function: a short linear segment for signal at or below 0.04045, then a power curve with exponent 2.4 and an offset — ((V + 0.055) / 1.055)^2.4. That linear toe exists so the curve has a finite slope near black, avoiding the infinite-gradient problem a pure power function has at V = 0. Pure gamma 2.2, by contrast, is V^2.2 everywhere, no toe.

At the midpoint the two curves are close enough to explain the myth: sRGB(0.5) ≈ 21.4% relative light, gamma 2.2(0.5) ≈ 21.8% — a difference under half a percentage point. But they diverge hardest exactly where the toe does its work: in the shadows. At V = 0.1, sRGB outputs about 1.00% while gamma 2.2 outputs about 0.63% — sRGB is roughly 60% brighter in the near-blacks. That gap is why swapping one for the other silently crushes or lifts shadow detail, even though a spot-check at mid-gray looks fine.

Gamma 2.4 and the dim-surround logic

Pure gamma 2.4 is the BT.1886 ideal-black-case reference EOTF most grading suites target — DaVinci Resolve's "Rec.709 Gamma 2.4" and most reference monitors in a darkened grading room. The higher exponent than 2.2 exists because of surround compensation: a viewing environment with very low ambient light (a grading bay) makes mid-tones look lower-contrast than the same signal would in a brighter living room, so the reference curve is deliberately steeper — about 18.95% relative light at 50% signal instead of sRGB's 21.4% — to restore the perceived contrast the dim surround would otherwise wash out. Gamma 2.2 approximates a "dim but not dark" surround (a typical office or living room), which is why it, not 2.4, is the practical assumption baked into most consumer displays and the sRGB standard itself.

PQ: the only absolute curve, and the 92-nit arithmetic

PQ (SMPTE ST 2084) is fundamentally different from the other four: it does not describe relative light, it describes absolute nits, engineered from a model of the human contrast-sensitivity threshold from 0.0001 to 10,000 nits. The formula uses five constants derived from that model — m1 = 2610/16384, m2 = 2523/4096 × 128, c1 = 3424/4096, c2 = 2413/4096 × 32, c3 = 2392/4096 × 32 — applied as L = 10000 × (max(V^(1/m2) − c1, 0) ÷ (c2 − c3·V^(1/m2)))^(1/m1).

Worked through by hand at V = 0.5: p = 0.5^(1/m2) ≈ 0.5^(1/78.844) ≈ 0.99125. Then max(p − c1, 0) = 0.99125 − 0.83594 ≈ 0.15531, and the denominator c2 − c3·p ≈ 18.8516 − 18.6875 × 0.99125 ≈ 0.16831. Dividing gives ≈ 0.92287, and raising that to 1/m1 (m1 ≈ 0.15930) gives ≈ 0.009225. Multiply by 10,000 and a 50% PQ code value carries only about 92 nits — not 5,000 nits scaled by half, not even close to half of a typical 1,000-nit HDR grade's peak. This is the single fact that trips up anyone reading PQ code values like a percentage: PQ's steep curve packs most of its dynamic range into the top quarter of the signal, so mid-signal values look deceptively dim in absolute terms. It's also exactly why an HDR grade played back — unconverted — on an SDR display looks wrong: the SDR panel interprets the same code values through its own relative EOTF instead of PQ's absolute one, and the mapping between "0.5 signal" and "how bright that should be" is completely different between the two systems.

HLG's relative philosophy, and the OOTF footnote

HLG takes the opposite design bet from PQ: instead of an absolute nit target, it stays backward-relative and scene-referred, using a and b and c constants (a = 0.17883277, b = 1 − 4a, c = 0.5 − a·ln(4a)) in a curve that's a simple square below 50% signal and a logarithmic segment above it — chosen so a legacy SDR display, ignoring HLG's HDR metadata entirely, still renders a broadly watchable (if flatter) picture. That's the point of the broadcast-friendly design: no metadata dependency, single-stream compatibility. Honesty footnote: what this comparator plots is HLG's inverse OETF — signal back to normalized scene light, E = V²/3 below 0.5 — not the light actually leaving an HLG display. A real HLG display applies an additional OOTF on top, with a system gamma of roughly 1.2 that itself depends on the display's peak luminance, to convert that scene-linear value into display light. The curve here is the comparable, display-independent form; it is not a finished EOTF the way PQ's is.

Practical guidance: why your web export looks lifted

If you graded in 2.4 (the dim-surround grading-room reference) and exported straight to a web player rendering through something closer to sRGB or gamma 2.2, the picture will look lifted and lower-contrast than it did on the reference monitor — exactly the gap this comparator plots in the shadows. The fix is a proper display LUT or a deliberate contrast trim for the delivery target, not eyeballing it against a memory of the grading suite. One sober note on QuickTime gamma-shift lore: older QuickTime/ColorSync pipelines did apply an unwanted gamma tag that shifted mid-tones on playback, but modern macOS/QuickTime and every current NLE handle Rec.709 tagging correctly — treat it as a legacy gotcha to rule out, not a live risk on current tools.

Matching curve to delivery target is the whole game: grade and monitor on gamma 2.4 in a controlled room, deliver SDR web/broadcast expecting gamma 2.2 or sRGB decode, and reserve PQ or HLG for an actual HDR delivery spec — PQ where the platform wants absolute mastering metadata (Dolby Vision, most streaming HDR10), HLG where broadcast-compatible, metadata-free single-stream delivery is the requirement.

1. Enable the transfer curves you want side by side: sRGB, gamma 2.2, gamma 2.4, PQ (ST 2084) and HLG (BT.2100).

2. Drag the signal slider to any code value from 0 to 1 and read each curve's display light, including PQ's absolute nit figure.

3. Toggle the log scale to open up the shadows, then compare the camera-side encodings in the Log Curve Comparison Plotter.