4:2:0 and 8 bits: where the colour went

Your picture has less colour in it than you think

Delivery codecs do not store a full colour value for every pixel. They store brightness for every pixel and colour for only some of them, because the eye is far more sensitive to changes in brightness than to changes in hue. The shorthand for how much colour survives is chroma subsampling, written as three numbers.

4:4:4 keeps a colour sample for every pixel. Full colour. Used in graphics work, ProRes 4444, and almost never in delivery.

4:2:2 halves colour horizontally: one colour sample per two pixels across. This is broadcast-grade, and it is what ProRes 422 and DNxHR carry.

4:2:0 halves colour both horizontally and vertically: one colour sample for every 2 × 2 block of four pixels. Three quarters of the colour information is gone before the codec even starts compressing.

Almost everything you deliver is 4:2:0, because that is what phone and television decoder chips do in hardware. Your camera probably shot 4:2:0 as well, unless it was an expensive one or you recorded externally.

Where you can see it

Most of the time you cannot, which is why the scheme survives. The places it shows are specific and predictable.

Saturated red on a dark background is the classic. Red carries most of its energy in chroma, so red text or a red line on black smears into a soft fringe. If a title looks crisp in the timeline and mushy after export, this is almost always why.

Thin coloured lines and small text, particularly in screen recordings of code editors with syntax colouring.

Hard colour edges — a graphic with a magenta panel meeting a cyan one will show a stepped, blocky seam under motion.

This has a practical consequence for the text block earlier in this course: heavier weights and larger sizes survive 4:2:0, and hairline coloured type does not. The advice to avoid thin coloured fonts is not taste. It is a codec constraint.

It also explains why keying a green screen shot from a consumer camera is so painful. The key lives entirely in colour, and in 4:2:0 the colour edge is a quarter of the resolution of the picture you are trying to cut out.

Bit depth and banding

Separately from how many pixels carry colour is how finely each value is recorded.

8-bit gives 256 levels per channel. 10-bit gives 1024. That sounds like a small difference and it is not, because the visible failure is not a loss of vividness but banding: a smooth gradient, such as a sunset or a studio backdrop lit from one side, rendered as a series of flat steps with hard edges between them.

A clear sky at dusk might legitimately need 400 distinct levels between horizon and zenith. At 8-bit you have 256 for the entire range from black to white, and perhaps 40 in the part of the range the sky occupies. The steps become visible, and once you have seen one you cannot unsee it.

Two things make banding worse. Grading is one: stretching contrast on an 8-bit file spreads its existing 256 levels further apart, which is why grading log footage shot in 8-bit is difficult. Compression is the other, because the encoder smooths noise away and noise was the only thing disguising the steps.

The fix nobody expects

Add a small amount of grain before export.

It sounds backwards. It works, and it is the standard trick in every finishing house. Banding is visible because the boundary between two levels is a clean contour your eye traces. Adding noise of roughly half a level of amplitude makes pixels near the boundary randomly fall either side of it, which converts a hard edge into a soft dither. The eye averages it back to a smooth gradient.

In Resolve, a very light Film Grain or a Noise node at low strength over the offending region does it. In free tools, ffmpeg can:

ffmpeg -i in.mov -vf "noise=alls=3:allf=t" -c:v libx264 -crf 18 out.mp4

Keep it subtle — strength around 2 to 4 in that filter. Enough to break the contour, not enough to notice as texture. The cost is bitrate, because noise is expensive to compress, so use it where the problem is rather than over the whole frame if your tool allows a mask.

The other genuine fix is to deliver 10-bit where the platform supports it, which for HEVC and AV1 it increasingly does. Ten-bit H.264 is possible and poorly supported, so it is not the route.

What to do about it in practice

Shoot the best chroma and bit depth you can afford, because the losses are cumulative and only the first one is recoverable. Grade and composite in a high-precision working space even if you deliver 8-bit 4:2:0 — Resolve's internal processing is 32-bit float regardless of your source, so the quantisation happens once at export rather than at every step.

Keep your masters 10-bit 4:2:2 (ProRes 422 HQ or DNxHR HQX) so that every future delivery is a first-generation encode from good material.

And design graphics knowing where they land: chunky, high-contrast, not relying on saturated red edges against black.

Honest limits

None of this is visible on a phone in daylight, and a good deal of the anxiety about chroma subsampling is misplaced for material that will be watched once on a train. The cases where it genuinely bites are text, graphics, keying and gradients. For a documentary interview in a room, 8-bit 4:2:0 delivery is completely adequate and always has been.

Today

Make a title card: pure red text on black, 1080p, at a thin weight. Export it as H.264 and view it at 100%. Then make the same card in white and compare the edges. That difference is 4:2:0.