Settings for signal ranges always loom as a source of imaging issues, especially when images are converted from RGB to Y’CbCr and back for applying 3D LUTs. In this article, we want to give an overview of where these topics are relevant on set and how to make sure that signal and device configurations match.
RGB and Y’CbCr Encoding
To reproduce an image for the human observer, almost the entirety of the imaging equipment used in media production relies on two “tricks” for encoding the spectral information of a physical scene:
- The first trick is to subdivide the image into rectangular (typically squared) pixels. These are the smallest elements of an image, and each pixel carries the information of its color.
- The second trick is to encode that color with just three numbers, typically named “red” (R), “green” (G), and “blue” (B). All the pixels with the same name are called a channel (for example, the “red channel” of an image containing only the values for the “red” light’s intensity of the scene).
Cameras have sensors with red-, green-, and blue-filtered photo sites, and displays and projectors are made of elements that can create a mix of red, green, and blue light. While all that technology is incapable of reproducing the original scene’s spectrum of light, it does a pretty good job creating the appearance of that original scene on the display for the human eye. This effect made the “RGB” encoding of image pixels one of the main concepts of digital imaging.
From the old days of analog TV, we inherited the “YUV” image encoding – with the Y’CbCr format being the variant for digital images.
Y’CbCr (as YUV) differs from RGB in that one channel (the Y’ channel) carries “luma”, representing the brightness information of the image. The other two channels (Cb and Cr) carry the color information in the form of color differences to the Y’ channel for blue and red (the missing green color is mathematically “hidden” in all three channels together).
The Y’CbCr encoding has (or had) two main advantages:
- Y’CbCr is backward compatible to black and white systems: If you omit the Cb and Cr channels, you are left with a perfect grey-scale signal (consisting of just the luma channel).
- The image information is split into channels so that the human eye’s most sensitive information (brightness) is all encoded in the luma channel. That allows to efficiently compress the image by reducing the resolution of the other two channels (which is called “chroma subsampling”).
While the first advantage slowly fades into oblivion, the second advantage is still used in its digital form to save bit rate (i.e., for transferring higher resolution or frame rate through the same cable). An example is Y’CbCr’s default 4:2:2 subsampling in a range of common SDI formats used on the film set.
Signal Ranges
From its analog history, Y’CbCr also inherited the concept of “headroom”. The headroom of analog signals was designed to make these signals more robust to visible image artifacts.
In live TV situations, it could (temporarily) happen that the signal of a camera gets out of its “regular” range, e.g., when the camera pans into a set light. When signals exceed the safe range of an analog circuit, the analog components create distortion or “ringing” while clipping the signal. This distortion can lead to all kinds of visible image problems. To avoid this, the specifications for analog video systems defined some headroom for signals. The headroom increased the signal range that is “uncritical” for the video system – while it is in fact not used for carrying visible information*.
With the specification of headroom, the analog problems of clipping are solved: The camera could overshoot into the headroom once in a while, and systems processing these signals would not distort yet. While that signal would be beyond the maximum white that a TV could display, the TV would still safely show its maximum white color for such a signal in the headroom – without adding any problematic image artifacts.
The Y‘CbCr encoding of the SDI signal still implements that headroom in the form of not-to-be-used code values. For example, let‘s consider the 10-bit signal of an SDI signal. 10-bits of information can encode 1024 different states (2^10 = 1024), typically used as code values numbered 0 to 1023.
- The “regular” values for the Y‘ channel‘s encoding (luma) are specified as just the values from 64 to 940. That is the range called “legal range” (other names are “video range”, “SMPTE range”, or “narrow range”).
- Outside of the legal range lies the headroom.**
When sticking to the standards for “legal range”, the code value 64 represents the blackest black that a display can reproduce, and the code value 940 the brightest white that a display can reproduce. Therefore, all values below 64 will result in the same black as code value 64, and all code values above 940 will result in the same white as the code value 940.
But the signal in the analog headroom could be “recovered” with a simple gain control (typically labeled “contrast” on TVs and analog video equipment), and also digital code values in the headroom are there and can be (mis-)used for actual image content.
That‘s where things can get ambiguous, and we will return to that topic in a bit. But before, let‘s talk about applying lookup tables and going back and forth between “legal range” Y‘CbCr and RGB.
Lookup Tables
Lookup tables (LUTs) are long tables of number-encoded colors that can be used to map the color of each pixel of an input image to a new color, thus creating a differently colored output image.
The colors in all common LUT formats are encoded as RGB colors, meaning that each color entry in the lookup table is represented by three values, one for “red”, one for “green”, and one for “blue”. One of the reasons for that is that LUTs have their origin in computer graphics, where pixels are usually encoded in RGB and not in YUV (Y’CbCr) as with analog video. In order to apply a lookup table to an image, this image also needs to be encoded in RGB.
So let‘s take a look at a LUT box as used on set. A LUT box is a device that can apply a LUT to a video signal. For that, the LUT box needs to:
- read the Y‘CbCr pixels from the video input,
- convert them into RGB,
- apply the LUT by looking up new RGB color values for the original RGB values,
- convert the pixels of the new RGB image back to Y‘CbCr, and finally,
- put these Y‘CbCr pixels on the video output.
We see that both a Y‘CbCR to RGB conversion and an RGB to Y‘CbCR conversion are needed to apply a LUT to a Y‘CbCr video signal.
Converting Between RGB and Y‘CbCr
To understand how the RGB to Y‘CbCr conversion works, we need to look back at the ranges of video signals again.
The luma channel (Y’) legal range of a 10-bit Y’CbCr signal goes from 64 to 940. That means that a fully white pixel with maximum brightness typically has a Y’ code value of 940. So what code values would we expect for the RGB encoding?
For RGB encoded pixels in computer graphics, a concept of “headroom” is not a requirement, so RGB typically uses all code values for encoding colors. If we assume a 10-bit RGB encoding (each channel goes from 0 to 1023), the fully white pixel from above would be equivalent to an RGB pixel with code values 1023 (and not 940) for all three channels R, G, and B – representing the brightest white color in RGB.
So the general conversion from Y’CbCr and back will include some scaling that adjusts the valid range of code values of Y’CbCr to the range of code values in RGB. Only with that scaling a LUT (that is made for RGB values) will map the right colors. When the LUT should process our full white pixel from above, you don’t want to look up the RGB value for RGB 940 940 940 (because that’s the mapping for a light grey), but RGB 1023 1023 1023 (because that’s the mapping for full white).
So far we’re good, but here comes the issue…
The Special Cases for “Full range” and “Extended Range” Video
Already in the early years of HD-SDI, the idea came up to use the unused and “wasted” headroom for transferring image information in digital Y’CbCr signals. The outlook of 15% more code values per channel has led to two main approaches for extending the use of code values beyond the “legal range”:
- Some systems with digital video (SDI) interfaces include settings for switching between “full range” and “legal range” video signals. These settings change all video processing of the device from a range of 64..940 to 4..1019 (remember the technically reserved code values 0..3 and 1020..1023) to extend the fidelity of the video. For example, these settings have been used for HD-CAM SR video tapes in some use cases.
- Some video-style cameras use the headroom above code value 940 for sending out “super whites” beyond white, similar to the analog cameras that allowed for highlights to reach into the headroom. That way the increased dynamic range of camera sensors beyond the “legal” white level of SDR monitors can be transferred for further use (such as color grading), without changing the default appearance on a monitor. Typically the code values from 64 to 1019 are used in an SDI signal, and that range is called “extended range”.
You can find a good overview of the different range names and some more background information in EBU R 103: “Video Signal Tolerance in Digital Television Systems” [1].
With file-based workflows used everywhere now, the first use case (“full range” settings) is not too relevant any more. There are much better ways to increase the bit-depth of an image today, for example, with RAW file formats or the use of OpenEXR.
But some of the latest digital camera systems adapted the use of “extended range” for the output of their “log” signals via SDI. So, for example, when the Sony Venice camera is configured for Slog2 or Slog3 output on its SDI interfaces, it uses the extended range for these signals. So the brightest white in a Slog signal is not encoded as code value 940, but somewhere in the extended range up to code value 1019.
Using Slog2 and Slog3 (as any other “log” format) comes with the need to apply some processing for proper viewing. Often, this is implemented as a 3D LUT (typically, as a “log to video” LUT). If we remember the default behavior of applying a LUT on a Y’CbCR signal (see above), we would lose all information of the Slog signal beyond code value 940, as that code value is mapped with the brightest color in the RGB LUT. Any “brighter” Y’ value would not be used and digitally clipped to the maximum brightness assumed for a legal signal.
To solve this, we need to add a second way for applying a LUT on a Y’CbCr signal, which anticipates meaningful image information in the extended range.
LUTs for LUT Boxes
To support both use cases (applying a LUT to a “legal range” as well as to an “extended range” signal), LUT boxes provide access to the full range signal. That way a LUT can always translate any input signal – no matter if it is in the legal, extended, or full range.
Some LUT boxes (such as FSI BoxIO) have a switch in their configuration utility software that lets the user choose if the LUT is applied to the legal range or the full range. A second setting lets the user choose if the output should be in legal range again or also in full range. The LUT box then applies the necessary scaling (and clipping) accordingly.
If a LUT box doesn’t provide such a switch it usually applies the LUT to full range. That means that the conversion to RGB does not include the scaling of the input signal from 64..940 to 4..1019. If you want to apply a LUT to a legal range signal with such a LUT box, the LUT needs to be made in a way that the active area of the LUT is limited to the range 64..940 in RGB code values***. Software like Livegrade adjusts LUTs loaded in the software to prepare for use with the configured range settings of the LUT device.
Best Practice for Different Cameras
Here comes not a complete list, but a few recommendations for settings for different video signals:
- ARRI LogC, Canon CanonLog2, RED Log3G10: These log signals are encoded in a legal range Y’CbCr signal.
- Sony Slog2/Slog3, Panasonic VLog: These log signals are encoded in an extended range Y’CbCr signal.
- Camera output set to Rec.709: This is almost in every case a legal range Y’CbCr signal.
- SDI inputs of professional monitors expect a legal range signal on default.
You can derive the LUT Box settings or the settings for your live grading software from this list. Simply configure what the system should expect as an input (for example, “legal range” for LogC, “full range” for SLog3) and what the output should be (typically “legal range” for a standard monitor configuration).
A few examples to illustrate this: The LUTs provided by the manufacturers are regular RGB LUTs for use on all RGB code values. If such a LUT should be applied to the SDI output of an Alexa camera, the “legal range” input setting will tell the software to modify the LUT so that the LUT box applies it only to the “legal range” of the incoming Y’CbCr signal. For a LUT for SLog3, the “full range” input setting tells the software that no scaling of the LUT is needed, and so that LUT box applies it to the full (extended) range of the signal.
Capturing and Output of Stills and Video
Capturing and playout of SDI signals is a related topic where video ranges play into. During capturing, the Y’CbCr signal from SDI is converted into an RGB image. That RGB image is then stored on disk for later use, such as the display on the computer screen and for SDI playout. To get that aspect right (ranges-wise), the capture process in the software again needs to know if the legal range or the full range should be packed into the RGB image. Livegrade offers such settings in both the capture device and the SDI output options.
Conclusion
Although “legal range” is the default for a lot of SDI setups, there are situations where you need to go beyond that. Some cameras simply put image data in the extended range. To handle this properly, you need to know the settings of the systems that need to deal with these signals – especially when LUTs are applied in the digital signal chain.
[1] EBU R 103 – Video Signal Tolerance in Digital Television Systems, https://tech.ebu.ch/docs/r/r103.pdf (last accessed 8. June 2021)
* Analog to the headroom specified for the highlights, there is also “toe room” specified for the black levels for different reasons, but the idea and the consequences are the same as for the headroom, and we will use the term “headroom” for both.
** The values 0..3 and 1020..1023 are not allowed to be used for image information at all in Y’CbCr for SDI signals (not even for headroom). These code values are reserved for timing and synchronization purposes. In file codecs based on Y’CbCr, the entire range of 0..1023 can be used for “full range” applications.
*** We are trying to avoid speaking of a “legal range RGB encoding” here. It’s less ambiguous if we leave “ranges” a term describing Y’CbCr signals.
