A clip looks washed out on one monitor and correct on another. Nobody changed the grade. The file carries a set of flags describing how its numbers should be interpreted, one of them is wrong, and every display that reads the flags is doing exactly what it was told.
These fields are metadata, not picture. They do not change a single pixel value. They change what a pixel value means, which is why a mismatch produces a picture that is wrong without being broken.
The three fields
Video carries three related descriptors, and specs usually name all three because naming one is not enough.
Colour primaries define the gamut — the exact chromaticity of red, green and blue, and therefore the range of colours the numbers can express. Rec. 709 for HD. Rec. 2020 for UHD and HDR. Broader primaries mean the same numeric value points at a more saturated colour.
Transfer characteristics define the relationship between the stored value and light output. This is the field usually meant by “gamma”, and it is where HDR actually lives:
- BT.709 — the conventional curve for SDR.
- PQ (SMPTE ST 2084) — absolute. A value maps to a specific brightness in nits, regardless of the display. Used by HDR10 and Dolby Vision.
- HLG (ARIB STD-B67) — relative, and backward compatible: the bottom of the curve is close enough to conventional gamma that an SDR display shows something reasonable. Broadcast favours it for exactly that reason.
Matrix coefficients define how RGB was converted to the luma-and-chroma form the file actually stores. Get this wrong and colours shift, most visibly in saturated reds and blues.
How the flags go wrong
Rarely by anyone deciding badly. Almost always by transit.
The transcode dropped them. A tool re-wraps or re-encodes and writes defaults instead of carrying the source values. The picture data is untouched; the labels are now generic, and a player falls back to Rec. 709 for something graded in Rec. 2020.
The camera tagged conservatively. Some cameras record wide-gamut material and flag it 709 anyway, on the reasoning that more software will do something sensible with it.
The grade and the tag disagree. Material graded in HLG, exported with a preset that writes 709. Now every display treats HDR values as SDR ones, and the result is flat and grey — the classic symptom.
Only some of the three were set. Primaries updated to 2020, transfer left at 709. Individually plausible, together meaningless.
The symptoms, and what they point at
The failure modes are distinctive enough to diagnose from a description:
- Flat, washed out, low contrast — HDR material being displayed as SDR. Transfer characteristics say 709 when the picture is PQ or HLG.
- Crushed blacks, blown highlights, over-contrasty — the reverse. SDR material tagged as HDR.
- Slightly wrong saturation, otherwise fine — primaries mismatch. Usually 2020 material read as 709 or the other way round.
- Colours plainly shifted, greens and magentas off — matrix coefficients. Rarer, and usually a transcode wrote the wrong value.
- Correct in one app, wrong in another — one of them ignores the flags. This is a clue rather than a bug: it tells you the flags disagree with the picture.
The last one is the trap. Because some tools ignore colour metadata and just show you the numbers, a file can look right in the app you check it in and wrong everywhere it is going.
An HDR flag is not proof of HDR
Worth stating plainly, because it is the assumption behind a lot of unhappy deliveries.
The metadata describes intent. It does not certify that the picture uses the range it claims. A file can be flagged PQ and contain material that never exceeds 100 nits, which is SDR content in an HDR wrapper — technically compliant, visually pointless, and it will be graded again by somebody downstream.
HDR10 deliveries also carry static mastering metadata: the mastering display's primaries and luminance range, plus MaxCLL and MaxFALL, the maximum content light level and maximum frame-average light level. These describe what was actually in the picture, and displays use them to decide how to tone-map. A file tagged PQ with no mastering metadata is incomplete for HDR10, and specs that ask for HDR10 will say so.
Checking flags catches the structural error — the file that says one thing and was graded as another. Confirming the picture genuinely uses the range needs measurement, and for most deliveries the structural check is the one that catches the actual problem.
Reading them across a folder
Individually, any inspector will show you these fields. The problem is the same as everywhere else in a delivery: one file is a moment, thirty files is an afternoon, and the mismatch is between files rather than inside one.
FileLister reads colour primaries and transfer characteristics per file during a scan, alongside bit depth and an HDR flag derived from the transfer curve, and puts them in sortable columns. The thing you are looking for is almost always an outlier: nineteen files reporting HLG and one reporting 709 is the file that came from a different session.
For a recurring delivery the check goes in a filter set — transfer characteristics equal to the expected curve, primaries equal to the expected gamut — and the exceptions come out as a list with the reason attached.
What to put in a spec
If you are writing one rather than receiving it, name all three fields explicitly and say what happens when they disagree. “HDR” on its own is not a specification; it does not distinguish PQ from HLG, and those two need different grades.
A usable clause looks like: colour primaries BT.2020, transfer characteristics ARIB STD-B67 (HLG), matrix coefficients BT.2020 non-constant luminance, 10-bit. Four values, no ambiguity, and every one of them checkable without opening the picture.
The alternative is what most specs currently say, which is “deliver in HDR”, followed some weeks later by a conversation about why it looks flat.