Color, Chroma Subsampling and HDR
A pixel's colour has to be encoded, and the choices behind that encoding decide both how rich the picture looks and how much bandwidth it costs. The starting point is the colour space — the defined range of colours a signal is allowed to represent. HD video uses ITU-R BT.709; UHD and wide-gamut work use the much larger BT.2020. Feed a BT.2020 signal to a display expecting BT.709 without converting it, and the colours come out wrong — under-saturated and washed out, because the wide-gamut values get squeezed into BT.709's narrower primaries (the classic "HDR looks flat on an SDR chain" symptom). The reverse — BT.709 content shown as BT.2020 — over-saturates instead.
Then there is chroma subsampling, a clever economy built on a quirk of human vision: our eyes are far more sensitive to brightness than to fine colour detail. So rather than store full colour for every pixel, video often keeps full brightness while sharing colour information between neighbouring pixels. 4:4:4 keeps colour fully intact, 4:2:2 halves the horizontal colour resolution, and 4:2:0 halves it in both directions — each step shrinking the data while most viewers notice nothing. The cost only shows up in fine coloured detail, which is exactly why text, graphics, and chroma-key work want 4:4:4 or 4:2:2 and are worth the extra bandwidth.
Bit depth is the third lever. 8-bit gives 256 steps per channel and 10-bit gives 1024, and those extra steps are what keep a smooth gradient like a clear sky from breaking into visible bands. HDR, high dynamic range, builds on 10-bit and wide gamut to carry a far greater range of brightness, encoded through transfer curves such as PQ (SMPTE ST 2084) or HLG (BT.2100). The thread running through all of it is familiar by now: every device in the chain has to agree on colour space, subsampling, bit depth, and HDR curve — and a careless conversion between them is precisely where colour goes wrong.
Match colour space end to end — a mismatch shifts every hue.