A brief guide to the most important image standards

Written by Phil Rhodes

Some of the most important aspects of producing video content in the modern age are governed by standards. Here is a brief rundown of some of the numbers we're most likely to encounter, and a quick summary of what they mean.

Years ago it was possible to plug a camera into a monitor and be reasonably sure that the resulting picture was correct, simply because there were only a few camera types and a few monitor types. Messing things up required extra, expensive equipment. Now, it's almost impossible to glance through an instruction manual without running into numbers, which reference obscure documents that can each describe a bewildering array of things.

Here then, is a rundown of some of the numbers we're most likely to encounter and a quick summary of what they mean. It's important to remember that these are standards documents trying to express things with great specificity. They are often only referred to casually in technical writing without really elaborating as to how the standard, or some part of it, may relate to what we're talking about. This can cause confusion. To avoid causing any more confusion, we should be clear about this being a brief overview that will gloss over many details in the interests of giving an easily-digested overview.

If this seems to overlook any standards you may have encountered, let us know and we'll do a second round.

Rec. BT.709 – High-definition basics

Title: “Parameter values for the HDTV standards for production and international programme exchange”
Organisation: International Telecommunications Union
First approved: 1990
Latest revision: June 2015
Documents: https://www.itu.int/rec/R-REC-BT.709/en

If you've ever wondered why high-definition TV usually has 1920 by 1080 pixels and goes at 25 or 29.97 frames per second, this is the standard saying so. It's essentially comparable to (and in some ways based on) BT.601, which specifies the same things for standard definition TV and dates back to the early 80s.

Frame rates include both interlaced and progressive scan plus the fractional frame rates required for compatibility with US (and derivative) colour broadcast systems. Interlacing is something later standards started to overlook, possibly in favour of simply running progressive scan images at higher frame rates. Even so, 709 does actually specify progressive scan 60fps modes, making 1080p60 legal from a standards perspective. 709 specifies both 8-bit and 10-bit encoding, as well as the valid range of values within those ranges.

Among the more complicated things 709 specifies are the colour primaries and the ways to convert between different colour formats. It's easy enough to pick a red, a green and a blue. The ones given in 709 are based on those possible with CRT monitors, leaving us using colours we probably wouldn't have picked otherwise. The more complex part of it is the conversion between R'G'B' and Y'CrCb (usually just called YUV or component) encoding. The differences between (basically) RGB and YUV are easy to google and a bit beyond this article, but suffice to say that they're crucially important to colour accuracy. Furthermore, they're used in every camera which has HD-SDI output.

There are some dead-ends in 709; things that were specified but fell out of favour. It talks about the long-dead 1035-line interlaced system which never really went anywhere and an 1152-line 25fps interlaced system which never went beyond the experimental stage.

Rec. BT.1886 – Brightness for (standard dynamic range) monitors.

Title: “Reference electro-optical transfer function for flat panel displays used in HDTV studio production”
Organisation: International Telecommunications Union
First approved: March 2011
Latest revision: As published
Documents: https://www.itu.int/rec/R-REC-BT.1886/en

1886 is a comparatively obscure piece of paper which we almost might say exists to correct an omission in 709. Perhaps notoriously so, 709 did not define (broadly speaking) how much light should come out of a monitor compared to how much signal level goes into it. Until the publication of 1886, the de facto standard had been the behaviour of CRT displays. With CRT reference displays becoming unavailable and manufacturers emulating them to various degrees of accuracy and with various different priorities, some sort of standard was clearly required.

There are only about five pages of actual content in 1886, although it does clear things up quite nicely. The only issue is whether we should really be limiting our current, vastly better technology to the level of emulating an approach that's been out of date for decades — which is sort of where 2100 comes in (see below.)

Rec. BT.2020 – 4K, 8K, high frame rate, and more colours

Title: “Parameter values for ultra-high definition television systems for production and international programme exchange”
Organisation: International Telecommunications Union
First approved: August 2012
Latest revision: October 2015
Documents: https://www.itu.int/rec/R-REC-BT.2020/en

Although the formal title of 2020 refers to ultra-high definition, it's probably most commonly referred to in the context of the extended colour gamut it defines. The extensions to resolution and frame rate are more or less what we'd expect over Rec. 709: resolution can double to roughly 4K or quadruple to roughly 8K, with the actual pixel dimensions being a straightforward multiple of 1920x1080. There are higher frame rates of up to 120p and the standard provides for either 10- or 12-bit sampling (there is, in theory, no eight-bit 4K.) This is all fairly straightforward.

The more complex part of it is the extended colour capability. Lots of standards in lots of industries describe colour gamuts (sRGB and Adobe RGB are common). Almost all of them specify the primary red, green and blue in terms of their positions on a CIE 1931 chromaticity diagram. Almost all of those specify primaries that are some distance from the edge of the coloured shape on that diagram, implying that the colour is not entirely saturated. Colours right at the edge of the diagram contain only one wavelength of light — they're monochromatic. Most gamuts use primaries which aren't right at the edge, so that the red contains some (very little) blue and green, for instance.

Rec. 2020 deliberately defines single-wavelength, monochromatic primaries right at the edge of the CIE diagram. This maximises the range of colour that can be represented, although it's unlikely that monitors (and extremely unlikely that cameras) capable of handling the entire range can be built. There have been rumours of monitors with coverage of over 90 percent using quantum dot technology (See: RedShark News, “Better lighting with quantum dots”) to produce very saturated primaries. The increase in bit depth specified is presumably intended to provide for more precision in encoding the wider colour gamut, as increasing the range of colour without increasing precision would risk quantisation noise (that is, banding) in areas of finely graduated colour.

Rec. BT.2100 – High dynamic range

Title: “Image parameter values for high dynamic range television for use in production and international programme exchange”
Organisation: International Telecommunications Union
First approved: July 2016
Latest revision: As published
Documents: https://www.itu.int/rec/R-REC-BT.2100/en

We've talked a lot about high dynamic range and the many things that define how it should work. It's probably worth having a look at our previous coverage (See: RedShark News, “Get ready for the HDR format war”) if terms like PQ and HLG are unfamiliar to you. In short, in sort of the same way that 1886 does for standard dynamic range pictures, these terms determine how much light comes out of a monitor in comparison to the amount of signal that goes in. Rec. 2100 is the ITU publication which defines PQ and HLG as operating standards.

It does not standardise PQ-based Dolby Vision, possibly because that's very much a for-profit, corporate effort. At the same time, we might hazard a prediction that HLG may continue to drift slowly out of favour, leaving PQ as the really important part of Rec. 2100.

Rec. 2100 also talks about the ICTCP colour encoding, which is rather like YCrCb, but different: it's designed to allow compression to work better with HDR images.

DCI-P3 – Digital cinema colour

Title: From SMPTE standards “Digital Source Processing — Color Processing for D-Cinema” and “D-Cinema Quality — Reference Projector and Environment”
Organisation: Society of Motion Picture and Television Engineers
First approved: November 2010 (SMPTE EG 432-1), April 2011 (SMPTE RP 431-2)
Latest revision: As published
Documents: (Behind paywall) http://ieeexplore.ieee.org/document/7289763 and http://ieeexplore.ieee.org/document/7290729

In common usage, DCI-P3 is often used to refer to monitors, specifically those intended to reproduce the colour gamut defined for digital cinema. This isn't nearly such a wide gamut as that defined in Rec. 2020, but it's more capable than say, Rec. 709.

The two SMPTE standards which mainly underlie P3 have a much broader scope than colour encoding alone. Engineering Guideline 432-1 draws together a lot of SMPTE standards that are connected with digital cinema, including those on technology and viewing environments. It discusses the processing that's necessary when preparing material for digital cinema exhibition as well as the decoding that needs to be done in projectors.

Quite often, though, P3 means a set of colour capabilities in a monitor.

ACES – Academy Color Encoding System

Organisation: Academy of Motion Picture Arts and Sciences
First approved: December 2014
Latest revision: As published
Documents: http://acescentral.com/c/resources/documents

The Academy Color Encoding System is an attempt to force some sort of an organisation into the vast range of cameras, displays, exhibition and distribution standards that exist. For instance, it’s possible to shoot in SLog3 with the SGamut3 colour gamut using a Sony camera, enter that information into Resolve so it can decode the image properly, and then have Resolve produce output that can be monitored on a display using the DCI-P3 colour primaries and brightness handling. With ACES, it should be possible to set all the controls to “ACES” and have everything work fairly straightforward.

In practice, at least part of ACES can be (reasonably accurately) seen as a standard set of conversions from, say Sony's colour and brightness encoding to a standard internal format, then back from that standard internal format to a distribution encoding such as that defined in Rec. 709. How much this helps depends on how widely it's adopted. So far, manufacturers seem to be hedging their bets somewhat, supporting ACES while maintaining their proprietary approaches as an alternative.

ACES defines a lot more than just colour transformations, however. The definition of the internal format to which everything is converted involves a very wide colour gamut using virtual primaries. Those are theoretical colours that can never possibly exist. They allow the mathematics to work in order to theoretically support any colour visible to a human and encoded in a digital representation that can handle enormous contrast ratios.

This is a very cruel abbreviation; ACES is simple in concept but involves a lot of complexity once we begin to examine the software that implements it and the options it opens up.

Tags: Production


Related Articles

2 August, 2020

This is how the first DV cameras changed video production forever

The 1980s were the decade when video began to encroach on film – certainly for TV, if not for cinema. The 1990s was the decade when digital cameras...

Read Story

1 August, 2020

This is one of the biggest influencers on modern video you might not have heard of

If you’ve started using cameras in the last few years you might not be aware of just how far cameras have come. For some time one of the go-to...

Read Story

31 July, 2020

Why do we keep thinking in 35mm for focal lengths?

Replay: Do we really need to keep using 35mm as our baseline for focal lengths, or is there a much better way?

Read Story