Why HDR so often looks wrong — and what the file is really telling your screen. Drag to compare.
Turn on HDR and there's a fair chance the picture gets worse — washed-out whites, crushed shadows, faces that look mildly sunburned. The feature ships on nearly every phone, TV, and laptop sold since the mid-2010s, and most of those screens cannot actually display it correctly; they accept the signal and improvise. The reason traces to a single design decision. For fifty years an image file never said how bright it should be. It said how bright relative to white, and left "white" up to the hardware. HDR's real innovation is not more brightness — it is that the file finally carries an absolute answer: the luminance of every pixel, in physical units, meant to be identical on every display that obeys the standard. This piece is about that shift from relative to absolute light, and about what happens in the gap between what the file promises and what the glass in front of you can deliver. Interactive demos abound.
SDR encodes light relatively. First, a unit. Luminance is the amount of light a surface sends toward your eye, measured in candelas per square metre (cd/m²), informally called nits. For scale: a phone screen indoors sits around 100–200 nits; a sunlit white wall, a few thousand; fresh snow in direct sun, north of 10,000 — and the sun's own disc is roughly 1.6 billion. An sRGB value of 1.0 (code 255) names none of these numbers. It means only maximum emission from this display. A cinema projector at 48 nits and a laptop at 500 nits read the same code and emit wildly different amounts of light, both technically correct. The gamma curve mapping code to light just stretches to fill whatever range the hardware has. This was deliberate: 1970s engineers building CRTs (cathode-ray tubes, the bulky glass picture tubes that predated flat panels) couldn't know the peak brightness of every screen their signal would reach, so they standardized a dimensionless shape and left absolute brightness to the hardware.
The cost surfaces the moment you put SDR and HDR content on the same display — an old photo beside a new one, a subtitle over an HDR film, a web page open on an HDR laptop. The display must decide how bright SDR's "white" should be, and nothing in the SDR signal tells it. Every standard gives a different answer: SMPTE RP 431-2 puts a reference cinema screen at 48 nits, ITU-R BT.1886 puts a calibrated SDR monitor at 100 nits, an HDR mastering display might run to 1,000. The number lives in the calibration, never in the file.
The fix starts with a distinction HDR can make and SDR never could: reference white is not peak white. Reference white — also called diffuse white — is the brightness of an ordinary white object under ordinary light: a sheet of paper, a painted wall, a white shirt. It is the anchor your eye reads as "this is what white looks like." Peak white is something else: the glint of sun on chrome, a bare bulb filament, a specular highlight on water. In SDR there was no room for the difference. Code 255 was both your sheet of paper and your sun, and anything brighter than "white" simply clipped to white. HDR's central move is to seat reference white well below the ceiling and reserve the headroom above it for the highlights that truly are brighter than paper.
So where should reference white sit, in nits? SDR mastering — set in an era of dim CRTs in dim rooms — anchored it near 100 nits. But on an HDR display, often viewed in a brighter room and surrounded by highlights running to thousands of nits, a 100-nit white looks muddy and grey. ITU-R BT.2408 studied this side-by-side viewing and settled on 203 cd/m² as the reference white for SDR content shown inside a PQ or HLG HDR environment.1 At 203 nits, an SDR white next to HDR content reads as the same white — neither dim nor blown out. The oddly specific figure isn't a rounded 200: it's the level BT.2408 found matched SDR white perceptually, and it encodes to a signal value of E′ ≈ 0.58 in PQ — notation that §2 makes precise (for now, read E′ as "a specific code value" and PQ as "the HDR encoding"). We'll read it straight off the curve there.
One wrinkle keeps this calibration empirical rather than arithmetic: the eye does not judge brightness by luminance alone. A saturated color looks brighter than a neutral grey emitting the exact same number of nits — the Helmholtz-Kohlrausch effect. Match two whites with a light meter and they can still look unequal to a person, which is why "how bright should white be" was settled by viewers under controlled conditions, not by a formula. In every comparison below, the SDR variant caps each pixel at this 203-nit reference white; the HDR variant keeps the same tonal foundation but lifts the brightest regions into the headroom above it, up to 4,000 nits.
Start from the mechanism. An image file is a grid of numbers — code values. A display is a grid of elements that emit light. Between them sits a transfer function: the rule that turns each stored number into a quantity of light (the EOTF — electro-optical transfer function — applied at the display) and, on the camera side, the inverse rule that turned light into numbers in the first place (the OETF, opto-electronic transfer function). That rule is never a straight line, and the reason is the eye.
Human brightness perception is roughly multiplicative, not additive. In a dark scene a tiny absolute change in light is glaring; in a bright scene the same absolute change is invisible. We notice ratios, not differences — and we notice a lot of them: the eye resolves on the order of 14 stops of contrast at once, far more with time to adapt. (A stop is the photographer's unit — one doubling of light; 14 stops is a range of 214, about 16,000:1.) If you stored light linearly across a fixed number of bits, you would lavish codes on the bright end, where the eye cannot tell neighboring steps apart, and starve the dark end, where it can — producing visible banding in shadows. A transfer function bends the code allocation to follow perception, spending bits where the eye actually looks.
For decades the answer was gamma: a power law, E′ = L1/γ with γ ≈ 2.2. Nobody designed that exponent for the eye. A CRT's light output happened to follow a roughly 2.2-power law of its drive voltage — a quirk of electron-gun physics, where the beam current steering electrons at the phosphor rose as about the 2.2 power of the control voltage — and that curve happened to be close to the inverse of how the eye encodes lightness. Encoding for the tube therefore encoded for the viewer, by accident. The catch is in the normalization: L runs 0 to 1, where 1.0 is "whatever this display emits at maximum." Gamma encodes a relative shape — a code of 0.5 means "partway to this display's max," and the max is left undefined by the signal. That ambiguity is exactly the reference-white problem from §1.
Perceptual Quantizer (PQ), developed at Dolby and standardized as SMPTE ST 2084 in 2014, makes the axis absolute. It fixes the domain once and for all: the range [0, 10,000 cd/m²] maps to the code range [0.0, 1.0]. Now a code does not mean "half of max" — it means a specific number of nits, identical on every conforming display. Ten thousand is a deliberate ceiling, not a limit of the math: outside of staring straight at a light source, almost nothing in human experience is brighter, so it is a cap chosen never to be hit.
The curve's exact shape is not arbitrary. It is fit to Barten's contrast sensitivity model1 — a description of the smallest brightness step a person can detect (the just-noticeable difference, or JND) at each luminance level. PQ is built so that one step in code value stays near one JND across the whole range: no step large enough to show as a band, none so fine that it wastes a code. At 12 bits the steps sit below the JND everywhere (that is Dolby Vision); even 10 bits (HDR10) is usually clean — where a linear encoding would need roughly 14 bits to dodge visible banding. The constants in the formula below are fit, not derived: tap any term for what it does, but the shape is the point, not the digits.
With the axis fixed, the encoded values become readable landmarks — trace them on Fig 2.2 below. At 100 cd/m² (old SDR grading white), E′ ≈ 0.51. At 203 cd/m² (the BT.2408 reference white from §1), E′ ≈ 0.58. At 1,000 cd/m² (a common HDR10 peak), E′ ≈ 0.75. At 4,000 cd/m² (the ceiling used for the comparison images in §4), E′ ≈ 0.90. The dashed gamma curve tells the other half of the story: with a 100-nit peak it has already reached E′ = 1.0 at 100 nits and then flatlines — it has no code left to describe 101 nits, let alone 4,000. Everything in the shaded region exists in PQ and is simply unrepresentable in gamma-encoded SDR.
Brightness is only half of headroom. The other half is color. A wide gamut adds the color headroom HDR needs, and the two go together. A gamut is the full set of colors a system can reproduce, fixed by its three primaries — the purest red, green, and blue it can emit — because every other color is a mix of those three. Narrow primaries mix to a narrow range of colors.
To picture a gamut, set brightness aside and plot color alone. The CIE chromaticity diagram does exactly this: a horseshoe-shaped map where every point is a distinct hue and saturation, the curved outer edge traces the pure single-wavelength (spectral) colors — the most saturated light physically possible — and the whole horseshoe marks the boundary of human vision. A display's three primaries are three points inside it; the triangle joining them is everything the display can show. A bigger triangle reaches more of the horseshoe, and therefore more of what the eye can see.
sRGB, the gamut of nearly every SDR image, draws a fairly small triangle. ITU-R BT.2020 (Rec.2020) draws a much larger one: its primaries sit almost on the spectral edge — approximately pure 630 nm red, 532 nm green, 467 nm blue — so its triangle stretches across most of visible color. On the diagram its corners are R (0.708, 0.292), G (0.170, 0.797), B (0.131, 0.046).3 No current consumer display can actually hit those primaries; the standard deliberately describes hardware that does not yet exist, so future panels need no re-encoding to use their full range.
Why does brightness demand this? Because the most intense real-world highlights are often deeply saturated — flame, neon, a sunset, sun through a colored leaf. In a narrow gamut you can make such a highlight bright only by desaturating it toward white as it climbs; a wide gamut lets it stay vividly colored and grow bright. Brightness without gamut turns every strong highlight pale.
A caveat for the images here. All four sources are ordinary sRGB JPEGs, so the conversion invents no color that was never captured — it repositions the chromaticity already in each file into the Rec.2020 coordinate system, passing through CIE XYZ under the D65 white point. In these photographs the visible change is mostly luminance headroom, not gamut; gamut matters most when the source holds bright, saturated color that sRGB had to clip.
There's a perceptual reason HDR's wider gamut and higher luminance reinforce each other, and it isn't in the signal at all — it's in the eye. The Hunt effect: as a color's luminance rises, the eye sees it as more colorful, not merely brighter. The same orange at 200 nits and at 2,000 nits is the same chromaticity on the diagram, but the brighter one looks more saturated. Its cousin, the Helmholtz-Kohlrausch effect from §1, says a saturated color already looks brighter than a grey of equal luminance.
Together they explain why a tone-mapped SDR image looks not just dimmer but flatter and greyer than its HDR counterpart: crushing the luminance doesn't only remove light, it withdraws the eye's own gain on brightness and saturation. The conversions in §4 hold chromaticity fixed and lift only luminance — yet the HDR halves read as more vivid, which is the Hunt effect doing the work the encoding set up.
| Image | Primary test | SDR constraint | HDR reveal |
|---|---|---|---|
| Sunset | Colored specular highlights | Orange sky flattened at 203-nit ceiling; ripple ratio collapsed | Glow at 650–1,700 nits; luminance separation in highlights |
| Basalt rocks | Shadow/midtone saturation | Grass/heather near ceiling with compressed separation from black | Midtones at 300–800 nits; HK saturation gain |
| Snowy valley | Highlight rolloff in near-white | Lit snow at ceiling; shadow transition in a 30-nit band | Lit snow at 800–1,200 nits; rolloff is an 8:1 ratio |
| Tunnel | Extreme dynamic range | Exit clipped to code 255; interior near-gray; contrast ≈ 2:1 | Exit at 4,000 nits vs. interior at 40–80 nits; 80:1 ratio |
| Neon alley | Saturated emissive color | Signage flattened toward white near the ceiling | Light sources above diffuse white, still vividly colored |
| Stained glass | Saturated transmitted color + DR | Glass or stone, not both | Backlit glass holds color while shadowed stone stays dark |
| Bonfire | Designed-for-HDR grade | — | Chroma boosted with luminance (a deliberate divergence) |
With the encoding and the gamut in hand, here is what the two regimes do to real photographs. Each image runs through one pipeline — sRGB → linear → Rec.2020 (via XYZ D65), a percentile-anchored tone map with a smoothstep S-curve — then splits into two luminance regimes: SDR capped at 203 cd/m², HDR lifted to 4,000 cd/m² through broad, highlight, and specular stages. Chromaticity is identical in both.2
Drag the handle to compare; the intensity slider is a rough proxy for HDR lift, not a true nit-level change.3 On a real HDR display with browser HDR support, the HDR side emits well above 203 cd/m² from the glass.
Everything above preserves chromaticity and changes only luminance. But once you have the headroom, you can grade for it. The figure below boosts saturation in proportion to luminance lift — deliberately leaning into the Hunt effect rather than letting the eye do all the work. It is a divergence from the chroma-preserving pipeline used everywhere else here, and on fire it earns its keep.
What the file now contains is a physical claim: this pixel is 600 nits, that one is 4,000. Whether you ever see it is a separate question. A panel that peaks at 600 nits, a browser with no HDR path, an operating system compositing HDR over an SDR desktop — each accepts the same file and then approximates, tone-mapping the signal down, sometimes badly. That is why HDR so often arrives washed-out or grey: not because the encoding failed, but because the hardware couldn't honor it and guessed.
The encoding side is settled. The 203-nit reference white, the PQ curve, the Rec.2020 gamut are absolute and the same everywhere. The gap that remains is between what the file specifies and what the glass in front of you can deliver — and for now, the file asks for more than most hardware can give.
opacity on the HDR image layer overlaid on the SDR layer — a visual approximation, not a true nit-level adjustment. True nit-level control requires re-encoding at the target peak or runtime WebGL tone-mapping. ↩