Colour Spaces: RGB, YCbCr, BT.709, BT.2020, DCI-P3

Published 2026-05-15 · 19 min read · By Nikolay Sapunov, CEO at Fora Soft

Why this matters

If you build any product that handles video — a streaming service, an online learning platform, a video editor, a telemedicine app — colour spaces will eventually cause you trouble. The symptoms are easy to recognise once you've seen them a few times: skin tones that look pale and bluish, a brand logo whose red doesn't match the print version, a 4K movie that looks dim and grey on one device and oversaturated on another. None of these are codec bugs. They're colour-space mismatches — somewhere in your pipeline, two stages disagree on which colour space the numbers in the file refer to. Once you understand how the system is supposed to work, every fix becomes obvious and most can be applied with a single command-line flag. By the end of this article you'll know which colour space to use for which type of content, what to ask your encoding vendor about colour metadata, and how to spot a mismatch on first viewing.

We're going to build the picture piece by piece — no prior knowledge required. We'll start from "what does it actually mean for a colour to be a number?" and work our way up through every term and standard in active use today.

How a colour becomes a number

Let's start at the absolute beginning. Colour is, physically, a property of light. White sunlight, when split through a prism, fans out into the rainbow — a continuous range of wavelengths from short (violet, around 380 nanometres) through medium (green, around 555 nm) to long (red, around 700 nm). Every visible colour is either a single pure wavelength or a mixture of many wavelengths reaching your eye at once.

Your eye doesn't have separate sensors for every wavelength. It has three kinds of colour-sensing cells, called cones, each tuned to a different overlapping range — one peaks at red-ish wavelengths, one at green-ish, one at blue-ish. The brain reads the relative strength of those three signals and constructs every colour you experience from that three-number signal. The colour "yellow" you see isn't a separate cone — it's red and green cones firing together. The colour "white" is all three firing roughly equally.

This biological quirk has one enormous engineering consequence: almost any visible colour can be reproduced by mixing the right amounts of three carefully-chosen reference colours. That's the foundation of every screen, every camera, every printer, and every colour standard in this article. If you pick three reference colours — call them a red, a green, and a blue — and you can adjust the brightness of each independently, you can synthesise nearly any colour your eye will accept as a match. The three reference colours are called the primaries.

So that's how a colour becomes a number. A camera measures the strength of red-ish, green-ish, and blue-ish light hitting each spot on its sensor, and writes those three numbers down. A screen takes three numbers and lights up its red, green, and blue sub-pixels at the corresponding intensities. The eye reconstructs the colour from the three primary lights.

That three-number system is the simplest colour space, and it has a familiar name.

RGB — the natural language of cameras and screens

RGB, short for Red-Green-Blue, is the colour space where each pixel is stored as three numbers — one for each of the three primary lights. A bright pure red is written (255, 0, 0): full red, no green, no blue. A bright pure blue is (0, 0, 255). A grey is something like (128, 128, 128) — equal portions of all three primaries together produce a neutral light. A bright yellow is (255, 255, 0) — full red and green, no blue.

The range 0–255 in these examples comes from storing each colour component as one byte of data — eight binary digits, capable of holding 256 different values. With three components per pixel, that's 256 × 256 × 256 ≈ 16.7 million distinct colours. We covered this in What is digital video.

RGB is the natural language of capture and display. A camera's sensor reads RGB directly — that's how the silicon is wired. A monitor's pixels are physically arranged as little red, green, and blue dots, so they display RGB directly. The format you see in a Photoshop colour picker, in a CSS file, in a graphic designer's Pantone reference — it's almost always RGB.

But here's where it gets interesting for video. Almost no video file on the internet stores pixels as RGB. Video uses a different colour space, and there's a clever reason why.

YCbCr — the format every video codec actually uses

If you look inside almost any video file produced for streaming, broadcast, or playback — Netflix, YouTube, your phone's camera roll, a Zoom recording, a Blu-ray — the pixels are not stored as RGB. They're stored as a different three-number system called YCbCr.

Here's how YCbCr works. Take the three RGB numbers for one pixel. Apply a small mathematical formula that combines them in different proportions. Out come three new numbers:

• Y is the luma — a single number summarising the pixel's brightness, mixed from all three RGB components in proportions chosen to match human vision. Y is roughly: 30% red + 59% green + 11% blue (the exact proportions vary by standard).
• Cb is the blue-difference chroma — a number describing how much more blue than green-tinted-grey the pixel is.
• Cr is the red-difference chroma — a number describing how much more red than green-tinted-grey the pixel is.

Why on earth do this conversion? It looks pointless — we still have three numbers, just different ones. The answer is the most important fact in this article: the human eye is far more sensitive to changes in brightness than to changes in colour. ¹

You'll instantly spot a bright detail going slightly fuzzy. You'll not notice if a colour detail goes slightly fuzzy, especially in moving footage. Try it with your phone camera right now — point it at something and slightly defocus only the colour. You'll struggle to see the difference.

This eye-asymmetry creates an enormous compression opportunity. If you've split brightness (Y) and colour (Cb, Cr) into separate numbers, you can spend lots of bits on Y, where the eye cares, and aggressively chop bits from Cb and Cr, where the eye doesn't. The technical name for that chopping is chroma subsampling, and we cover the precise mechanics in Sampling and the Nyquist theorem applied to video. The short version: by encoding colour at half the resolution of brightness — a format called 4:2:0 — codecs cut the data per pixel roughly in half before any other compression even starts, and the result still looks great to a human eye.

That trick alone is why every video codec in commercial use — H.264, H.265 (HEVC), AV1, VVC — works in YCbCr, not RGB. The conversion happens automatically when video is encoded, and it gets reversed automatically when the file is decoded for playback on your screen. The viewer never sees YCbCr; the YCbCr layer is the codec's working format.

Figure 1. RGB to YCbCr. Same pixel, same information, just rearranged. Three numbers describing red, green, and blue become one number for brightness plus two for colour difference. The arrangement is what makes video compression possible.

A note about a third term you'll meet: YUV. YUV is the analog-broadcast ancestor of YCbCr — the same idea of separating brightness from colour, but designed for analog TV transmission in the 1950s. Modern digital files use YCbCr, but the names YUV and YCbCr get used interchangeably in casual conversation, in tool documentation, and in some old codecs. When somebody says "YUV 4:2:0" they almost always mean "YCbCr 4:2:0." Treat them as synonyms.

Why three numbers aren't enough — colour spaces inside the family

So far we've talked about families of colour space: RGB and YCbCr. But within each family, you need to specify a more detailed agreement. Two different cameras can both produce RGB files, but if they disagree on what "red" means, the pixel value (255, 0, 0) will look different on each.

To see why, let's think about screens for a moment. Different screen technologies can actually produce different colours when their red, green, and blue sub-pixels are turned on full. An old TV's red is a slightly different red from a modern OLED phone's red. A cinema projector's red is different again. They're all called "red," but they're not the same physical wavelength of light. So when a video file says (255, 0, 0) — "make this pixel full red" — which red?

The answer has to be agreed in advance, or the picture will look wrong on different devices. The agreement is a colour space standard. A colour space standard pins down three things:

1. The exact primaries. Which red, which green, which blue do the numbers refer to? This is specified as precise points on a scientific colour diagram (we'll get to that in a moment).
2. The white point. When all three primaries are at full intensity, what colour is the resulting "white"? Different lighting conditions produce different whites. A blue-tinted "white" from a fluorescent office lamp is not the same as the warm white of an incandescent bulb. Most modern colour spaces standardise on D65, a white that matches average daylight at 6500 Kelvin — the colour temperature of a slightly overcast noon sky. ²
3. The transfer function (gamma curve). How does a number value (say, 128) translate into actual light brightness? Spoiler: it's not linear; the relationship is curved to match how human eyes perceive brightness. That's a whole separate topic that we cover in Transfer functions: gamma, PQ, and HLG. For now, just know it's part of the agreement.

Without those three specifications nailed down, "(255, 0, 0)" has no agreed meaning. The video file would be ambiguous.

The colour diagram you'll see everywhere

Before we list the actual standards, we need one quick scientific tool. In 1931 the International Commission on Illumination (the CIE) ran experiments on dozens of human observers and produced a 2D map of every colour the human eye can see, called the CIE 1931 chromaticity diagram. ²

The diagram is shaped like an upside-down horseshoe. The curved outer edge represents pure single-wavelength colours — the rainbow, from violet on the bottom-left curving up through green at the top, to red on the bottom-right. The flat bottom of the horseshoe (called the "line of purples") represents non-spectral purples made by mixing red and violet. The inside of the horseshoe contains every mixed colour the eye can produce — white sits roughly in the middle.

This diagram is the universal reference. Every colour space standard is defined by drawing a triangle inside the horseshoe, with the three corners marking the exact positions of its red, green, and blue primaries. The area inside the triangle is the colours that standard can reproduce — its gamut. Anything outside the triangle is a real colour the eye can see but that standard cannot represent.

Figure 2. The CIE 1931 chromaticity diagram. The horseshoe contains every colour a human eye can perceive. Each colour space draws a triangle inside it; only colours inside the triangle can be reproduced. Bigger triangle = more colours. The white dot at D65 is the standard daylight reference.

Now the standards.

BT.709 — the colour space of HD video

BT.709, also called Rec. 709, is the dominant colour space for High Definition video. It was published by the ITU (the International Telecommunication Union, the standards body in charge of broadcast definitions) in 1990, just as HDTV was being designed. ³ Almost every video shot, edited, and streamed in 1080p Full HD or 720p HD uses BT.709 unless you have a reason to do otherwise.

BT.709's primaries are deliberately conservative. The triangle is relatively small — only about 36% of the colours a human eye can see fall inside it. That sounds restrictive, but in 1990 it was the most that mass-produced CRT and early LCD displays could actually reproduce. There was no point in standardising on colours that no consumer screen could display.

If you've ever worked with sRGB — the standard colour space for web graphics, JPEG photos, and PNG images — you've already used BT.709's gamut. The two standards specify essentially the same triangle on the CIE diagram. ⁴ sRGB is for still images, BT.709 is for video, but the colours they can represent are the same. That's why your phone photos and your phone videos look colour-consistent without any conversion.

For any HD video product in 2026, BT.709 is the default and the safe choice. Every device, every browser, and every operating system in commercial use understands BT.709. Use it unless you have a specific reason to push into a wider gamut.

DCI-P3 — the colour space of digital cinema

DCI-P3 is the colour space defined by the Digital Cinema Initiatives, a consortium founded by the major Hollywood studios in 2002 to standardise digital movie projection. The "P3" stands for "Projector 3." DCI-P3 was finalised in 2010 and is the colour space every commercial cinema projector in the world uses today. ⁵

DCI-P3's triangle is noticeably larger than BT.709's — about 54% of human-visible colour falls inside it, with significantly more vibrant reds and greens. ⁶ If you've watched a recent Hollywood film in a cinema and noticed how much richer the colours look than on a typical TV at home, you've seen the difference between DCI-P3 and BT.709. That difference is real, not your imagination.

In recent years DCI-P3 has spread beyond cinema into consumer devices. Almost every modern Apple device — iPhones since 2015, recent MacBooks, the Pro Display XDR, and Apple TV 4K hardware — uses a slight variant of DCI-P3 called Display P3 as the native colour space. Many high-end Android phones, recent Samsung and Sony TVs, and several PC monitors do the same.

This creates a real problem for product teams. If you encode video in plain BT.709 and serve it to a viewer on a Display P3 device, the viewer's hardware can show more vibrant colours than your file is using — the picture looks acceptable but flat. If you encode in P3 and serve to a BT.709 device, the colours look wrong unless the player explicitly converts between them. Modern operating systems handle this transparently if your file is tagged correctly. We'll talk about tagging at the end of this article.

BT.2020 — the colour space of 4K and HDR

BT.2020, also called Rec. 2020, is the colour space for Ultra High Definition (4K and 8K) video and for HDR (High Dynamic Range) content. It was published by the ITU in 2012 alongside the first 4K standards. ⁷

BT.2020's triangle is enormous — about 76% of human-visible colour. ⁶ It pushes into deep blue-greens (a turquoise that no BT.709 system can reproduce), vivid pure reds, and extremely saturated greens. The increase from BT.709 to BT.2020 is roughly the same step that BT.709 was from old SD-era colour: a major widening of what's representable.

There's a catch: almost no consumer display in 2026 can actually reproduce the full BT.2020 gamut. The best OLED and Mini-LED screens cover 70–80% of it; cheaper screens much less. So BT.2020 is mostly an aspirational standard — files are encoded in BT.2020, the display does its best to show what it can, and the rest is approximated. The reasoning is forward-looking: if Hollywood masters a film in BT.2020 today, the film will still look correct on the better displays of 2030 and 2035 without re-mastering. ⁸

For HDR content (Dolby Vision, HDR10, HDR10+, HLG), BT.2020 is the colour space of choice. Almost every HDR file you've ever watched is tagged as BT.2020 internally even if the actual colours used inside the file fall within the smaller DCI-P3 triangle. We'll go much deeper on HDR in The complete guide to HDR.

Side-by-side: BT.709, DCI-P3, BT.2020

To pin everything down in one place:

The three triangles nest neatly inside one another on the CIE 1931 diagram. Anything BT.709 can represent, DCI-P3 can represent. Anything DCI-P3 can represent, BT.2020 can. That nesting is why the standards can co-exist — content authored in a wider gamut can be downconverted to a narrower one without too much loss, while content authored in a narrower gamut can be served as-is to wider-gamut devices.

There's also a forgotten ancestor — BT.601 (Rec. 601) — that defined the colour space for standard-definition digital video back in 1982. You'll occasionally still see it in legacy systems and old DVDs. Its gamut is similar to BT.709 but uses slightly different conversion math between RGB and YCbCr. If you receive material tagged as BT.601, your player needs to know — the wrong math produces visibly off colours.

Where this all goes wrong — and how to spot it

The whole system hinges on one thing: every video file has to carry metadata declaring which colour space its pixel values belong to. That declaration is called the colour space tag, and it's how the player on the other end knows whether (255, 0, 0) means BT.709-red or BT.2020-red.

When the tag is correct, everything works. The player reads the tag, applies the right conversion for the display it's running on, and the colours match the creator's intent. When the tag is missing, wrong, or ignored, you get colour mismatches. ⁹

The three failure modes a product team will see in the wild:

Failure 1: missing tag, player guesses wrong. A video file is encoded without colour-space metadata. The player defaults to BT.709 because that's the safest assumption. If the file was actually authored in BT.2020 or DCI-P3, every saturated colour in the picture will look washed out — pinks instead of reds, pale teals instead of saturated greens, dim blues. The fix is to add the metadata; the FFmpeg flags are -color_primaries, -color_trc, and -colorspace.

Failure 2: tag says one thing, content is another. A file is tagged as BT.709 but the pixel values were actually computed for BT.2020. The player honours the tag, applies BT.709 interpretation, and the picture looks oversaturated — the wide-gamut numbers get plotted onto narrow-gamut primaries, producing colours far outside what they should be. Reds turn into searing fire reds, greens become neon. This is what people mean when they say "this video looks oversaturated" — usually the tag is wrong, not the content.

Failure 3: pipeline strips the tag at some stage. The original file is authored correctly, but somewhere in the encoding pipeline (often during a downsampling or format conversion step), the colour-space metadata is dropped. The next stage in the pipeline doesn't know what colour space it's looking at and falls back to a default. Every step in the pipeline that touches video must preserve or correctly re-write colour metadata, or you'll see colour drift.

The simplest diagnostic test is to run ffprobe (a free tool that ships with FFmpeg) against any file you receive and read out the colour metadata. If the fields are blank, you have a tagging problem upstream. Fix it there, not in the player.

# Inspect a file's colour-space tags
ffprobe -v error -select_streams v:0 \
  -show_entries stream=color_primaries,color_transfer,color_space,color_range \
  -of default=noprint_wrappers=1 input.mp4

A correctly-tagged HD file will return something like:

color_primaries=bt709
color_transfer=bt709
color_space=bt709
color_range=tv

A 4K HDR file should return bt2020 for primaries and colour space. If you see unknown or empty fields, the pipeline upstream is missing colour metadata.

Figure 3. The colour space tag has to flow end-to-end through your pipeline. Every stage that touches the video must preserve or correctly rewrite the tag. The red warnings mark the three most common drop-points we see in production audits.

Practical guidance: which colour space for which product?

The right choice depends entirely on your content type and target audience. Here's the rule of thumb we use at Fora Soft when scoping a new project:

If you're not sure, the answer is almost always BT.709. It's the universal default. You only step up to DCI-P3 or BT.2020 when you have a deliberate reason — premium content, HDR support, or a specific device matrix.

Common mistake: working in RGB and "converting at the end"

A common workflow we see at clients goes: "Let's do all our editing and colour correction in RGB, then convert to YCbCr only at the final encode step." This sounds clean but is actually the source of dozens of subtle colour issues. The conversion from RGB to YCbCr is lossy in YCbCr's narrower brightness range — bright highlights get clipped, deep shadows get crushed. If you work in RGB and convert once at the end, every clipped highlight and crushed shadow is final.

The professional approach is to work in YCbCr (or in a high-bit-depth log format if you have HDR sources) from the moment the file enters your pipeline. Tools like DaVinci Resolve, Adobe Premiere, and FFmpeg all support YCbCr workflows natively. The output is more consistent and the round-trip conversions are minimised.

Where Fora Soft fits in

We see colour-space bugs constantly because we work across the whole pipeline — telemedicine systems pulling from old hospital cameras, OTT platforms transcoding user uploads, conferencing apps composing multiple streams together, surveillance systems archiving from a dozen camera brands. Almost every weeks of work includes at least one ticket along the lines of "the colours are wrong on iPhone but correct on Android" or "the live feed looks washed out compared to the recording." The fix is almost always upstream of where the problem was reported: a missing tag, a stripped tag, or a transcoding step that didn't preserve the metadata. The framework in this article is the one we apply every time.

What to read next

• What is digital video: from analog signal to bits
• Sampling and the Nyquist theorem applied to video
• The complete guide to HDR: HDR10, HDR10+, Dolby Vision, HLG

Talk to us · See our work · Download

Talk to a video engineer — bring your colour-space problem and we'll scope a fix. · See our work — 239+ shipped multimedia projects across OTT, conferencing, surveillance, and telemedicine. · Download the colour space audit checklist — one-page PDF that walks an end-to-end pipeline and flags every place colour metadata can get lost.

References

Supplementary references: Rec. 2020, Wikipedia, https://en.wikipedia.org/wiki/Rec._2020 · Color space, Wikipedia, https://en.wikipedia.org/wiki/Color_space · Color gamuts explained: sRGB, DCI-P3, Rec 2020, Android Authority, https://www.androidauthority.com/color-gamuts-guide-3035782/ · FFmpeg colour metadata documentation at https://ffmpeg.org/ffmpeg-all.html