4.7 Full and Legal ranges

4.7.1 Legal Range

When image data is stored or transmitted in an integer form, such as DPX files or over SDI signals, it is necessary to map the levels in the image to the available code values. When digital representation of video signals was devised, it was decided to allow for overshoot and undershoot outside the range from black to white, in order not to clip analog signals which might not sit accurately within that range. Thus it was decided that black should be coded as 8 bit 16 or 10 bit 64, and white should be coded as 8 bit 235 or 10 bit 940. This coding is referred to by a number of names, including Legal Range, SMPTE Range, Narrow Range, Video Range, and Head Range. The mapping from an output referred float representation (v) where display black is represented by 0.0 and display white by 1.0 can be generalized as follows:

legal = round(2(n - 8) ? (16 + 219 ? v))

where n is the encoding bit depth.

4.7.2 Full Range

The alternative is simply to use all the available integer code values to encode the range from black to white. This approach is unable to represent so-called "super-white" and "sub-black" (or "super-black" - a contradiction in terms, because the Latin prefix "super" means "above") values. This coding is referred to as Full Range, Data Range or CG Range. It is also sometimes confusingly called RGB Range, due to to the fact that Y’CbCr coding uses legal range to code the Y’ signal, so RGB is deemed to use the alternate coding, even though this is not always the case. Full range coding can be generalized as:

full = round(v ? (2n - 1))

where again n is the encoding bit depth.

A third encoding exists which uses the range from 64-1023 in 10 bit to encode the signal. This is sometimes called Extended Range coding or SMPTE+, and is sometimes used for HLG, although the term Extended Range may also be used to refer to Full Range coding. This kind of ambiguity regarding terminology makes discussion of the issues related to range complex. For the sake of simplicity, this document will ignore Extended Range, as that relates primarily to broadcast video. For completeness, the equation for SMPTE+ is given here:

SMPTE+ = 2(n - 4) + v ? (2n ? 2(n - 4) ? 1)

where n is the bit depth, and v is the 0.0-1.0 normalized HLG signal being encoded, for example.

Even when discussing full and legal range there is still the possibility for confusion, as some applications use the two terms to mean the opposites of the definitions given here. And also, for example, when choosing the ’legal’ option in an application it is important to understand whether this means that the image data is to be ’treated as’ legal range or ’scaled to’ legal range. Some additional confusion is caused by the fact that because of the overshoot and undershoot capabilities of legal range coding, it is able to code ’illegal’ pixel values - that is values outside the 0-100

These codings date back to the early days of digital video, where the analog signals being coded had specific meanings for ’black’ and ’white’ in terms of video level. When using an integer coding to represent a log signal, the log values 0.0 and 1.0 no longer have particular significance, and their meaning varies between the different log codings. The reference 10 bit code values of a log signal are those which are created in a DPX exported from the manufacturer’s raw decoding software, but the way those values are mapped to the SDI code values output by the camera (and hence also the values stored in Y’CbCr based recording formats such as ProRes) varies between manufacturers.

ARRI, for example, have chosen to map their LogC coding to the legal range of the SDI output of their cameras (previously there was a menu option to map it to full range - which was referred to as ’Extended’ - but this is no longer available) and to do the same with the code values sent to the ProRes encoders in their cameras. Because during decoding most software ProRes decoders apply a legal to full scale to the legal range values used internally in ProRes, lens cap black will appear as 9.3

Sony, on the other hand, maps their cameras’ S-Log3 encoding to the entire range of code values available on the SDI output of the camera, and send the same value to the encoders for their internal recordings. So S-Log3 lens cap black will appear at 3.5

Correct linearization, using ACES Input Transforms, for example, is reliant upon the image data input to the transform being appropriately scaled. A ProRes log recording from a Sony (or Canon or Panasonic) camera is one of the situations where errors are likely to occur. If an S-Log3 ProRes recording is handled in the standard manner, which is appropriate for an ARRI or RED recording, a legal to full scale will be applied (possibly automatically and invisibly by the decoding software, as happens in Nuke for example) inappropriately, meaning that the sensor black level will be mapped to too low a code value, resulting in negative values after linearization. It is important to look out for this, as the result may not be immediately apparent, simply resulting in slightly crushed shadows when viewed through the display transform.

There is further complexity caused by the fact that in ’baked video’ modes Sony cameras map the video black to the white range to the legal range of the SDI output and internal recordings. This means that different scaling is required in post for log and video recordings. Sony’s proprietary internal recording formats contain metadata, identifying the image data as log or baked video, and some applications are able to automatically scale the decode based on this. However, it is always worthwhile checking that scaling has been applied correctly. Most ProRes decoders have no way of knowing whether the recorded image is S-Log3 or baked video (ProRes recordings will often come from external recorders, which simply receive an SDI signal with no information about the content) so it is up to the user to set the correct scaling.

Avid software is unusual in decoding ProRes without scaling, so LogC black will appear by default as 0.116 (8 bit code value 30) in the Avid UI. But because no scaling is applied to SDI output from Avid, the signal will still be at 9.3

Hardware LUT boxes or LUT processors built into monitors apply simple 3D cubes, without shaper LUTs or defined input domains. They, therefore, map an input range from 0-1 to an output range of 0-1, but it varies from device to device whether this 0-1 range is mapped from the full range 0-1023 SDI code values at the input of the LUT box, or the 64-940 legal range within those code values. Likewise, the 0-1 output of the LUT will normally be mapped to output SDI code values using an inverse of the input scaling. Some LUT boxes have control software which allows the user to select input and output scaling, but many work in only one mode, and it is often not clearly documented what that mode is. Therefore when building a LUT to be applied in a hardware LUT box, it is vital to ascertain what mapping the LUT box uses. Often this can only be done by loading specifically designed LUTs (such as LUTs where every table value is equal to 940/1023) into the LUT box and checking the output on a waveform monitor.

In conclusion, it is crucial that you check your pipeline to ensure that any scaling between legal and full range is only being applied where necessary, and is happening in the correct direction. Look out also for "double scaling" where a scale is applied unnecessarily because one has already been applied invisibly by the application. Part of the round trip testing that you should always perform is to make sure that any scaling applied at the start of the VFX pipeline is inverted at the end of it so that what is passed to DI matches the original media, if it is sent in the original format. If sent as scene-referred linear EXR files they must match the result of a linearization performed in the DI system on the original media, using an ACES Input Transform for example. Equally, it is important to confirm that color baked renders for editorial match the graded dailies of the original plates. Due to the different handling of range scaling by different NLEs, and the options for the editor to change the interpretation of the files, the only way to be certain of this is by thorough testing.

Output-referred image shown as intended

(b) The same image with a full-to-legal scale inappropriately applied. Note the raised blacks and clipping below peak white.

(c) The same image with a legal-to-full scale inappropriately applied. Both whites and blacks are clamped.