showstack

The direct answer

What #ffffff actually is

Three channels — red, green, blue — one byte each. A byte holds 0 to 255, and one byte is exactly two hexadecimal digits, which is the entire reason colours are written in base 16 rather than base 10: ff is unambiguous and two characters wide, where 255 is three characters and needs separators.

So #ff8800 is red 255, green 136, blue 0. Send those same three numbers down a lighting universe to an RGB fixture and you get the same instruction. A web colour and a DMX value are the same object arriving by different routes.

#fff is shorthand: each digit is doubled, so it expands to #ffffff. And #ffffff is every channel at maximum, which is why it is white — not because white is a colour, but because it is all three primaries at full.

Why 255 and not 100

Bit depth, again

Eight bits per channel gives 256 levels; three channels gives about 16.7 million combinations. That is 16.7 million codes, not 16.7 million distinguishable colours — the two are frequently confused in marketing.

Ten bits gives 1024 levels per channel and a bit over a billion codes. The reason to want that is not richer colour; it is gradients. A slow fade to black, a soft sky, a subtle wash across a large LED wall — these are where 256 steps become visible as bands, and where a large surface makes each step physically wide.

This is the same fact as bit depth in audio and 16-bit fixture control: resolution buys you steps small enough that nobody can see the join, and past that it buys storage.

The thing that surprises everyone

The numbers are not linear light

Half the code value is not half the light. Feed 128 out of 255 into a normal display and you get roughly 22% of the brightness of 255, not 50%.

That is deliberate. Human brightness perception is roughly logarithmic — we can distinguish far more steps in the dark than in the light, which is the dark adaptation story from the other side. If you spent 256 codes evenly on linear light, almost all of them would be wasted at the bright end where nobody can tell them apart, and the dark end would band horribly. So a transfer function is applied before storage that distributes the codes to match perception.

It is perceptual compression, and it is the only reason 8-bit video is watchable at all. It is also the source of a whole family of faults.

RGB is a recipe, not a colour

Which red is #ff0000?

The number says "the red primary, at full". It does not say what that primary is. Two displays with different red phosphors, different LEDs or different filters will both show you their maximum red, and those two reds will be visibly different colours.

A colour space is what closes that gap. It defines three things: the chromaticity of the primaries, the white point, and the transfer function. Given those, the same numbers mean the same colour on any display that honours them.

That is why a screenshot looks different on two monitors, why an LED wall needs calibration rather than just configuration, and why a camera, a media server and a wall all have to be told which space they are working in.

The compression nobody mentions

Chroma subsampling

The eye resolves far more spatial detail in brightness than in colour. Video exploits that: RGB is converted into one luma channel plus two colour-difference channels, and then the colour channels are stored at reduced resolution.

The notation counts samples in a four-pixel-wide block. 4:4:4 keeps full colour resolution. 4:2:2 halves it horizontally. 4:2:0 halves it horizontally and vertically — a quarter of the colour samples, and half the total data.

For camera footage of the real world this is nearly invisible and enormously useful. For anything with hard colour edges it is not: text, fine graphics, and keying. Coloured text over a contrasting background at 4:2:0 develops visible fringes, and a green-screen key at 4:2:0 has a quarter of the edge information a clean key needs.

The fault that catches everyone

Full range against limited range

Computer graphics use the whole byte: 0 is black, 255 is white. Broadcast video does not — it puts black at 16 and white at 235, leaving footroom below and headroom above for signals that overshoot.

Both conventions travel down the same cable in the same eight bits, and nothing in the picture announces which one it is. Get it wrong in one direction and blacks are crushed and whites clipped; get it wrong in the other and the image is washed out and grey with no true black.

This is the most common video fault on a show, it looks like a grading problem rather than a signalling one, and the fix is a setting rather than a colour correction. When a laptop looks washed out on a wall that was fine yesterday, check this before anything else.

The round trip

Light in, numbers, light out

Everything above is the middle of a journey that starts and ends in the physical world.

Capture. Photons land on photodiodes and accumulate charge — the image sensor story. That charge becomes a voltage, an analogue-to-digital converter turns it into numbers, and those numbers are linear light at that point. Then the Bayer mosaic is interpolated into full colour, a matrix converts the sensor's native primaries into a standard space, and a transfer function is applied. Only after all of that do you have the numbers a file contains.

Display. The reverse, and the last step is physical again. The transfer function is decoded, the values are mapped onto the display's actual primaries, and something emits light. On an LED wall a driver chip switches each LED fully on and fully off very quickly — the LED has no dimmer — and the ratio between on and off is the level. On a DLP projector, micromirrors flip. On an LCD panel, liquid crystal modulates a backlight.

Which is why an LED processor talks about grayscale bit depth and refresh rate in the same breath: grayscale is how many on/off ratios the driver can produce, and refresh is how fast it repeats the pattern. Both are invisible to an eye and entirely visible to a camera — see genlock and LED walls and flicker fusion.