The scene on screen is a candle-lit hallway with a blown-out window at the end, and it looks spectacular—deep shadows, a window that seems genuinely bright. You screenshot it, open the image, and find a smudged frame: the window is a dull white smudge, the shadows are flat, everything is wearing a coat of gray. Nothing is broken. The screen and the screenshot disagree because they are reading the same numbers with different rulebooks. High dynamic range video doesn't store colors as a simple brightness scale from zero to one; under the PQ system standardized in ITU-R Recommendation BT.2100, it stores code values defined against absolute physical light levels, up to a ceiling of 10,000 nits. Your TV decodes those values with the HDR rulebook and lights its pixels accordingly. The screenshot pipeline grabs the values, drops the rulebook, and hands them to an ordinary viewer that assumes the old sRGB scale. Two decoders, one file—only one of them is wrong. The disagreement is an old one in new clothes: every screen argument, from why a backlit TV's black glows gray in a dark room onward, is about what numbers mean once they become light.

Brightness as a code, not a setting

Standard dynamic range grew up with an implicit bargain: pixel values are relative, and each display maps them onto whatever brightness it has, from a phone in the shade to a living-room TV. That flexibility is why SDR screenshots look fine anywhere—there is no absolute meaning to lose. HDR broke the bargain on purpose. The PQ curve assigns each code value a specific luminance in candelas per square meter, spread perceptually across a range far wider than any single display can show. A value near the top of the scale doesn't mean 'bright-ish'; it means something like 'several hundred to thousands of nits', the light of a real window or an explosion. That precision is what lets an HDR TV make highlights look genuinely luminous rather than merely white, the same screen-side honesty behind a glowing dark screen—displays are physical light sources, and HDR finally acknowledges it.

What the screenshot actually grabs

When you press the capture keys, the operating system has choices. If it understands the HDR content, it can tone-map—toy with the values so the screenshot looks reasonable in SRGB—or save an HDR-aware file that carries the mapping forward, the way Google's Ultra HDR photo format embeds an SDR base image plus a gain map so the picture looks right on every screen and richer on HDR ones. But plenty of paths still do the naive thing: read the pixel values as they were being presented, strip the HDR metadata that says 'these are PQ codes', and write a plain image. An SDR decoder then interprets PQ values on the sRGB curve. Because PQ spends most of its code range on the bright end of human vision, the values for an ordinary scene—mid-tones and highlights alike—cluster in the lower-middle of the scale. Decoded as sRGB, that cluster reads as pallid: lifted blacks, dull highlights, everything compressed toward the middle. Gray, in other words, is not a color the screenshot added. It is where the misread numbers land.

One code value, two decodersIllustrative mapping, not a measured transfer function
HDR screen decodes itCode 700 ≈ a bright highlight, rendered with headroom above it
SDR reader decodes itSame code 700 read on the sRGB curve ≈ mid-gray, flat and pale

The stored number is identical; the interpretation curve decides whether it means 'bright' or 'gray'.

The mismatch runs both directions. Some pipelines overexpose rather than gray-out, if the HDR-to-SDR handoff applies the wrong reference white. The common thread is that the conversion step—tone mapping, the art of compressing a 10,000-nit scale onto a 100-nit one, with judgment calls about what to preserve—is exactly the step that got skipped. Broadcast engineers' HDR implementation reports spend whole chapters on tone mapping because there is no single correct answer; a screenshot that skips it has chosen the worst one.

Why some captures come out fine

You may have noticed the problem is inconsistent: the same phone behaves differently in different apps. That is because the screenshot pipeline differs. Capturing from the system video player may go through an HDR-aware path; capturing from a browser tab may not; a TV's built-in capture or a phone photograph of the screen involves yet another translation. The saved format matters too—a file carrying HDR metadata (gain maps, PQ signaling) can look washed out in one viewer and correct in another, which parallels the way photographs of screens acquire rainbows that were never in the image: the capture layer leaves its fingerprints. If you are sharing a frame of a film, the most faithful move is to let a player export the frame through its own tone mapping, or to accept that what you are sharing is a reinterpretation, not the original light.

There is a smaller-scale cousin of all this that you have probably already met: the faint rings in dark gradient wallpapers, where too few numeric steps show through a smooth ramp. Banding is what numeric poverty looks like inside one rulebook; a gray HDR screenshot is what changing rulebooks mid-file looks like. Both artifacts are honest—they are the numbers showing through the picture.

So the next time a captured frame arrives looking like fog, you can diagnose it in one glance: highlights dull, blacks lifted, colors desaturated, and the exact same scene glowing on the screen behind it. The screen kept the rulebook. The screenshot didn't. And if you want a gentle demonstration of how much interpretation sits between stored values and seen color, Broken Slider hides one misbehaving control among honest ones—the digital-color equivalent of noticing which decoder is lying to you.