Copyright Β© 2026, Society of Motion Picture and Television Engineers. All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.
The Society of Motion Picture and Television Engineers (SMPTE) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEβs Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTEβs Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual.
For more information, please visit www.smpte.org.
At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights.
This document was prepared by Technology Committee 10E.
This clause is entirely informative and does not form an integral part of this Engineering Document.
Computing and compositing systems must often render multiple sources of content, including text, images, and videos, that can be both standard dynamic range and high dynamic range, on the same display, at the same time.
Modern operating systems and compositors accomplish this by combining the sources of content in a common relative linear color space, with the target display's capabilities parameterized by a targeted high dynamic range headroom. Content with a high dynamic range headroom higher than the targeted high dynamic range headroom parameter must be adapted to the target display's dynamic range to prevent clipping and loss of detail. Similarly, content with a high dynamic range headroom lower than the targeted high dynamic range headroom parameter can be enhanced to improve the visual experience. Figure 1 provides a visualization of this process.
Color Volume Transform Application #5 defines dynamic metadata items that provide parameters for the steps in the above-described compositing pipeline of converting to relative linear color space and headroom-adaptive tone mapping to a targeted HDR headroom.
The metadata set of Application #5 is modular by design. The HDR reference white metadata item is always present, while the headroom-adaptive tone mapping metadata item is optional.
Conversion of the input image essence through its native EOTF produces linear display light which allows each source to be mapped into a relative linear color space using a metadata item parameter to specify the HDR reference white for each content source, as described in Clause A.2. In this conversion, the HDR reference white (with values measured in cd/m2) provides an anchor above which the HDR headroom begins.
Headroom-adaptive tone mapping transforms the input image essence so that the resulting tone mapped image has an HDR headroom equal to a specified targeted HDR headroom parameter, as described in 6.2. This operation is parameterized by metadata items specifying the baseline HDR headroom and potentially, multiple alternate images. Each alternate image is represented by an alternate HDR headroom and a corresponding color gain function. Each color gain function is specified in the domain via a component mixing function and gain curve as described in 6.3.
Adaptation to the specified targeted HDR headroom parameter is performed by applying a weighted average of the color gain functions. The weighting is performed using a function of the targeted HDR headroom, the baseline HDR headroom, and the alternate HDR headroom(s). This is described and illustrated with examples in Annex B.
This standard specifies the metadata for the Color Volume Transform Application #5. It is a specialization of the content-dependent transform metadata entries and processing blocks of the generalized color volume transform model defined in SMPTE ST 2094-1:2016.
It includes parameters for conversion of an input image essence to a common relative linear color space, parameters for a headroom-adaptive tone mapping algorithm, and the mathematical definition of that headroom-adaptive tone mapping algorithm.
Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.
All text in this document is, by default, normative, except: the Introduction, any clause explicitly labeled as "Informative" or individual paragraphs that start with "Note:"
The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.
The keyword "reserved" indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword "forbidden" indicates "reserved" and in addition indicates that the provision will never be defined in the future.
A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described.
Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; tables shall be next; then formal languages; then figures; and then any other language forms.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
For the purposes of this document, the following terms and definitions apply:
The symbol represents the set of all real numbers.
The symbol represents the set of all integers numbers.
The expression represents the set of integers .
The expression represents the interval from to including both endpoints.
The expression represents the interval from to excluding both endpoints.
A color volume transform structure defines the parameters for the color volume transformation informatively described in Annex A.
A color volume transform structure is parameterized by:
a real value representing HDR reference white in cd/m2
an optional headroom-adaptive tone map structure defining a function
The value of shall be in the interval .
A headroom-adaptive tone map structure defines a function which takes as parameters an input color in the gain application color space and a targeted HDR headroom , and returns a tone mapped color.
NOTE ββ The function performs the headroom-adaptive tone mapping, so when it is applied to the baseline image the resulting image will have an HDR headroom equal to the specified targeted HDR headroom.
This structure is parameterized by:
a real value representing the baseline HDR headroom
an integer number of alternate images
real values for representing the alternate HDR headroom of each alternate image
color gain function structures that define the function for each representing the color gain function associated with each alternate image
real valued vectors , , , and , indicating the ISO/CIE 11664-1:2019 CIE 1931 chromaticity coordinates from of the red, green, and blue color primaries and white point of the gain application color space
The value of shall be in the interval .
The value of shall be greater than or equal to 0 and less than or equal to 4.
For , the value of shall be in the interval .
For it shall be the case that .
For it shall be the case that .
The length of the vectors , , , and shall be 2.
The values of the components of the vectors , , , and shall be in the interval .
This clause lists constraints that are useful for achieving coherent headroom-adaptive tone mapping behavior. Implementations may adjust metadata items so that they satisfy these constraints.
For each , let be the function defined by the gain curve structure parameter to . It should be the case that:
This has the effect that when a headroom-adaptive tone mapping is performed with the targeted HDR headroom parameter set equal to an alternate HDR headroom, pixels in the baseline image with values equal to the baseline HDR headroom are mapped to values equal to that alternate HDR headroom.
For all :
This has the effect that, for a given pixel value in the baseline image, the headroom-adaptive tone mapped pixel values monotonically increases as the targeted HDR headroom increases.
If , then the tone curve function is monotonically decreasing.
If , then the tone curve function is monotonically increasing.
When tone mapping to a targeted HDR headroom that is equal to an alternate HDR headroom, the result of tone mapping is the corresponding alternate image. In symbols, for any , the function shall satisfy the equality in Formula (1).
The equality in Formula (1) is satisfied by the function defined in Formula (5).
This clause describes the evaluation of the function given an input color in the gain application color space and a targeted HDR headroom .
Create a new list of HDR headrooms by inserting the baseline HDR headroom into the list of alternate HDR headrooms in its sorted position. Let be the length of this new list and let be the list. Let be the list with the zero color gain function inserted at the position where was inserted.
These lists are constructed in order to simplify the presentation by reducing the number of special cases. In this formulation, the presentation does not need to distinguish between the case of interpolating between the baseline image and an alternate image and the case of interpolating between two alternate images, because they are unified into a single list.
Implementations can avoid explicitly forming these unified lists as an optimization.
A visualization of an example in which is inserted at the end of the list is shown in Figure B.1. A visualization of an example in which is inserted at the beginning of the list is shown in Figure B.3. A visualization of an example in which is the only entry in the list (because ) is shown in Figure B.4.
Let be the per-component gain in space. This is computed as a weighted combination of color gain functions evaluated at . The weighting depends on the value of parameter.
If there exists a value such that then shall be equivalent to the result of the definition in Formula (2).
Otherwise, there exists exactly one value such that .
Let and be the weights of the -th and -th color gain functions. These weights shall be computed as defined in Formula (3).
The value of shall be equivalent to the result of the definition in Formula (4).
The headroom-adaptive tone mapping function shall be equivalent to the definition in Formula (5).
Figure 2 provides a visualization of the computation of an alternate image as described in 6.2.4.
Figure 3 provides a visualization of the evaluation of the function as described in 6.2.5.
A color gain function structure defines a color gain function .
A color gain function structure is parameterized by:
a component mixing function structure, which defines the function
a gain curve structure, which defines the function
NOTE ββ The resulting color gain function is equivalent to an adaptive gain curve from ICC Adaptive Gain Curve.
This clause describes the evaluation of the function , given an input parameter .
Let be the component mixing function evaluated at , as defined in Formula (6)
The function shall be equivalent to the definition in Formula (7).
NOTE ββ If it is the case that all components of are equal, then the function needs to be evaluated only once.
The zero color gain function shall equal the color gain function defined in Formula (8).
NOTE ββ The zero color gain function is the color gain function that is applied to the baseline image when performing headroom-adaptive tone mapping with the targeted HDR headroom parameter equal to the baseline HDR headroom.
Figure 4 provides a visualization of the evaluation of the function as described in 6.3.2.
A component mixing function structure defines a function .
A component mixing function structure is parameterized by:
NOTE 1 ββ The function is constructed such that for any , there exists a such that . This means that, when applied to color values, maps grey values to grey values.
NOTE 2 ββ This function and its parameterization are the same as the adaptive gain curve input evaluator from Annex 1 of ICC Adaptive Gain Curve.
The values of , , , , , and shall be in the interval .
It shall be the case that .
This clause describes the evaluation of the function , given an input parameter .
Let be the part of the component mixing function that is common to all components. It shall be equivalent to the definition in Formula (9).
The function shall be equivalent to the definition in Formula (10).
NOTE ββ If the parameter is equal to zero, then all three components of will be equal.
A gain curve structure defines a function .
A gain curve structure is parameterized by:
The value of shall be greater than or equal to 1 and less than or equal to 32.
For , the value of shall be in the interval .
For , the value of shall be in the interval .
For it shall be the case that . If it is the case that then it shall also be the case that .
This clause describes the evaluation of the function , given an input parameter .
For , let be the th component of the gain curve, as defined in Formula (11).
The function shall be equivalent to the definition in Formula (12).
A metadata set shall comprise exactly one of each of the following:
The TimeInterval group shall include exactly one of each of the following metadata items defined in Clause 8 of SMPTE ST 2094-1:2016:
The ProcessingWindow group shall include exactly one of each of the following metadata items defined in Clause 9 of SMPTE ST 2094-1:2016:
The ColorVolumeTransform group shall include the following metadata items:
The HeadroomAdaptiveToneMap group shall include exactly one of each of the following metadata items:
Each AlternateImage[a] group shall include exactly one of each of the following metadata items:
Each ColorGainFunction[a] group shall include exactly one of each of the following metadata items:
Each ComponentMix[a] group shall include exactly one of each of the following metadata items:
Each GainCurve[a] group shall include exactly one of each of the following metadata items:
Each GainCurveControlPoint[a][c] group shall include exactly one of each of the following metadata items:
This clause specifies the constraints on the metadata set from 7.1, and defines the association between the items of the metadata set and data structures and parameters defined in Clause 6.
The ApplicationIdentifier metadata item shall equal 5.
The ApplicationVersion metadata item shall equal 0.
The ProcessingWindow shall be subject to the following constraints.
The ColorVolumeTransform metadata group specifies a color volume transform structure. The metadata items in this metadata group specify the parameters listed in 6.1.1, and are subject to the constraints listed in 6.1.2.
The HeadroomAdaptiveToneMap metadata group, if present, specifies a headroom-adaptive tone map structure. The metadata items in this metadata group specify the parameters listed in 6.2.1, and are subject to the constraints listed in 6.2.2.
The ColorGainFunction[a] metadata group specifies a color gain function structure. The metadata items in this metadata group specify the parameters listed in 6.3.1.
The ComponentMix[a] metadata group specifies a component mixing function structure. The metadata items in this metadata group specify the parameters listed in 6.4.1, and are subject to the constraints listed in 6.4.2.
The GainCurve[a] metadata group specifies a gain curve structure. The metadata items in this metadata group specify the parameters listed in 6.5.1, and are subject to the constraints listed in 6.5.2.
The metadata set for Application #5 may be carried by mechanisms that use the Recommendation ITU-T T.35 codes for non-standard facilities.
When using such mechanisms, Application #5 shall be identified by country code 0xB5 (United States), terminal provider code 0x0090 (SMPTE), and terminal provider oriented code 0x0001. The metadata set shall be encoded using the binary encoding described in Annex C.
In systems that support metadata carriage using Recommendation ITU-T T.35 codes in both the codec and the container, carriage in the container shall take precedence over and be preferred over carriage in the codec.
This annex describes the computations to apply the color volume transformation to an input image essence. Figure A.1 illustrates this specification's headroom-adaptive tone mapping algorithm in the framework of the Generalized Color Transform Model described in Annex A and visualized in Figure A.1 of SMPTE ST 2094-1:2016.
The individual stages of Figure A.1 correspond to Figure A.2, followed by Figure 3, followed by Figure A.3.
This clause describes the computation of the function , which converts an input signal to a color in the gain application color space.
Throughout this clause, the input signal is assumed to have three components corresponding to its red, green, and blue primaries, scaled such that the nominal peak signal is and the black signal is . It is also assumed to have transfer characteristics that determine its non-linear encoding and opto-optical transfer function. This corresponds a normalized coded signal according to Recommendation ITU-R BT.2100-3. These assumptions are to simplify the presentation, and are not a limitation on the types of input signal that can be used with this color volume transform. Similar computations can be used for non-normalized input signals (e.g., quantized and limited range signals) and for different coded input signals (e.g., or ).
The computation is visualized in Figure A.2, and represents the "Convert to Gain Application Color Space" block of Figure A.1.
Let be this input signal value.
NOTE 1 ββ Components of can be outside of the interval. This can occur due to multiple reasons, including coding and chroma format conversion. For example, a signal coded using a narrow range representation can intentionally contain values greater than the nominal peak signal or values less than the black signal as mentioned in Note 9a of Recommendation ITU-R BT.2100-3. Further information can be found in Section 2.4 of Report ITU-R BT.2408-8.
NOTE 2 ββ Scalar functions applied to vector arguments are applied component-wise.
Let be the value of the HDR reference white parameter specified by the HdrReferenceWhite metadata item.
Let be the electro-optical transfer function which converts an input signal value to RGB components of luminance in cd/m2.
NOTE 3 ββ When referring to the luminance of a single color component, it means the luminance of an equivalent achromatic color with all three color components having that same value.
The function for some common video signal transfer characteristics is as follows:
If the baseline image indicates Recommendation ITU-R BT.709-6 or Recommendation ITU-R BT.2020-2 transfer characteristics, then let be defined as in Formula (A.1), which is equivalent to the reference electro-optical transfer function defined in Annex 1 of Recommendation ITU-R BT.1886, with parameters and .
NOTE 4 ββ For this and other standard dynamic range transfer characteristics, the function evaluated at the nominal peak signal value will equal . The resulting color value in gain application color space, after applying Formula (A.3), will be .
NOTE 5 ββ An input image essence that originates from video that did not indicate its transfer characteristics is often assumed to have Recommendation ITU-R BT.709-6 transfer characteristics.
NOTE 6 ββ This formulation is equivalent to the display referred mappings described in Section 5.1.2, Section 5.1.3.1, Figure 5, and Figure 7 of Report ITU-R BT.2408-8, and in MovieLabs Best Practice: SDR to HDR Conversion. When in a context dominated by Recommendation ITU-R BT.2100-3 Hybrid Log-Gamma (HLG) content, some systems can choose to include an extra OOTF gamma adjustment step (using ) in Formula (A.1), as described in Section 5.1.3.2 and Figure 8 of Report ITU-R BT.2408-8. Implementations can use the formulation indicated by the content or the application context for this and other standard dynamic range transfer characteristics.
If the baseline image indicates IEC 61966-2-1 sRGB transfer characteristics, then let be defined as in Formula (A.2), which is multiplied by the function listed in Equations 5 and 6 of Chapter 5 of IEC 61966-2-1.
If the baseline image indicates Recommendation ITU-R BT.2100-3 Perceptual Quantization (PQ) transfer characteristics, then let be the PQ Reference EOTF as described in Table 4 of Recommendation ITU-R BT.2100-3.
If the baseline image indicates Recommendation ITU-R BT.2100-3 Hybrid Log-Gamma (HLG) transfer characteristics, then let be the HLG Reference EOTF as described in Table 5 of Recommendation ITU-R BT.2100-3, with parameters , , and .
NOTE 7 ββ The HLG Reference OOTF in this formulation must be applied using the color primaries indicated in Table 2 of Recommendation ITU-R BT.2100-3.
Let be the 3x3 matrix that converts color primaries from the baseline image color primaries to the color primaries of the gain application color space. The matrix is computed using chromatic adaptation (if needed) as defined in Annex E of Specification ICC.1:2022.
The function can be computed as defined in Formula (A.3).
This clause describes the computation of the headroom-adaptive tone mapping algorithm.
Let be the targeted HDR headroom that characterizes the capabilities of the target display. This can be computed as of the ratio of the peak luminance of the display to the luminance at which HDR reference white will be displayed, or it can be computed by other means outside of the scope of this specification.
Since the Application #5 metadata is modular by design, the HeadroomAdaptiveToneMap metadata group could have been omitted by the content creator. In this case, the headroom-adaptive tone mapping can be decided by the output system.
Otherwise, let be defined by the headroom-adaptive tone map structure parameter specified by the HeadroomAdaptiveToneMap metadata group.
Let be a color from the baseline image, in the gain application color space. Let be the color resulting from applying the headroom-adaptive tone mapping algorithm to that color. The value of can be computed as defined in Formula (A.4).
The transformation from gain application color space to the targeted system color volume can account for viewer preferences, non-reference ambient viewing environments, and other factors. The details of this transformation are outside of the scope of this document.
This clause describes a simplified illustrative example transformation from gain application color space to the targeted system color volume using linear scaling. The computation is visualized in Figure A.3, and represents the "Convert to Target Color Volume" block of Figure A.1.
Let the function be the function that computes the components of the luminance in the targeted system color volume. Let be the input tone mapped color in the gain application color space. Let be the targeted system white display luminance, which is the luminance at which HDR reference white will be displayed given the current user settings and ambient viewing environment. Let be the 3x3 matrix that converts color primaries from the gain application color space primaries to the targeted system color primaries.
The function can be computed as defined in Formula (A.5).
NOTE ββ Any colors that do not fit in the targeted display color volume (any colors with components greater than in the relative linear color space with color primaries of the targeted display color volume), can be projected (often by clamping component-wise) to the targeted display color volume.
Figure B.1 illustrates the color gain functions and associated tone mapping functions of a headroom-adaptive tone mapping with a baseline high dynamic range headroom , and a standard dynamic range alternate image with .
On the left side of Figure B.1 are the underlying color gain functions in the domain. The zero color gain function inserted corresponding to the baseline image is indicated with a solid line. The alternate image's color gain function is indicated with a dashed line. The control points for the gain curve parameter of the color gain function are indicated using filled circles.
On the right side of Figure B.1 are the tone mapping curves that are computed from the color gain functions. The zero color gain function results in an identity tone mapping function. The alternate image's color gain function results in a tone mapping curve that maps to , which corresponds to the standard dynamic range version. The mapping of the color gain function's gain curve's control points are indicated using empty circles.
Adaptation to a different targeted HDR headroom of is indicated using a dotted line. Its adapted color gain function is computed as a weighted averaging of the color gain functions on the left. The weighting parameters are . The resulting adapted tone mapping curve on the right maps to .
Figure B.2 illustrates a slightly more complicated example of headroom-adaptive tone mapping with an additional alternate image with . This new alternate image indicates that, when tone mapping to a targeted HDR headroom of , the color values below 1 in the relative linear color space (signal values below HDR reference white) are preserved and that highlights (signal values above HDR reference white) are to be compressed more aggressively.
An example adaptation to a targeted HDR headroom of is included. The adapted color gain function in this instance is a weighted averaging of the two alternate images' color gain functions. The weights in this example are and . The resulting adapted tone mapping curve on the right maps to .
Figure B.3 illustrates an example of inverse tone mapping with a standard dynamic range baseline image with , and a high dynamic range alternate image with .
This example is the inverse of the transformation performed in the example in Clause B.1. That is to say that a baseline image set to the alternate image from the example in Clause B.1 (the tone mapping to standard dynamic range), with this metadata, would appear identical to the example in Clause B.1, up to any quantization errors.
Note in the legend that in this example, because is inserted at the beginning of the merged list of HDR headrooms in 6.2.5.
Adaptation to the targeted HDR headroom of is indicated using a dotted line, as was also done in the example in Clause B.1.
The way to indicate that no tone mapping is to be performed, and that the baseline image is to be projected (clamped) to the target color volume, regardless of the targeted HDR headroom, is to specify that the number of alternate images is 0. This clause illustrates this behavior by working through the details of the computation.
In the context of the headroom-adaptive tone map computation described in in 6.2.5, this means that and therefore . The only entry in the constructed list of HDR headrooms is , and the only entry in the constructed list of color gain functions is , which equals the zero color gain function. The value of is set by Formula (2) and is . Finally, the function as defined in Formula (5) evaluates to be the identity, as worked out in Formula (B.1).
This means that the image resulting from the headroom-adaptive tone mapping in the color volume transform step in Clause A.3 is the unchanged baseline image. After this, the image is converted to the target display as described in Clause A.4, and the resulting image is projected to the targeted color volume, as described in Clause A.4, Note. The result of this operation is to clamp the baseline image to the targeted HDR headroom.
Figure B.4 illustrates this case, where the color gain function is always equal to the zero color gain function and the headroom-adaptive tone mapping is the identity.
Figure B.5 illustrates the result of this operation described in Clause A.4, Note, which is to project (or clamp) the baseline image to the targeted HDR headroom.
The metadata for Application #5 may be stored in binary form according to the syntax structure in Clause C.2. The assignment of values to the items of the metadata set based on the syntax elements is in Clause C.3.
The syntax structures are presented in a tabular form. The type of each syntax element in the bitstream is indicated in the Type column. A syntax element with type u(N) is stored as an N-bit unsigned integer. The bits of each syntax element shall be read in order from most significant to least significant.
NOTE ββ All syntax elements that are one full byte or larger are byte aligned. For syntax elements that are 16-bit unsigned integers, this representation is equivalent to storing those syntax elements in big-endian form.
Syntax elements with the name reserved_zero shall be equal to zero.
Table C.1 presents the syntax structures related to Application #5.
The smpte_st_2094_50_application_info metadata bitstream may have padding after the end of the structure. Parsers shall stop reading after the last recognized syntax element of smpte_st_2094_50_application_info and ignore all remaining data.
The minimum_application_version syntax element indicates the minimum application version that a parser needs to support in order to parse the smpte_st_2094_50_application_info metadata bitstream and perform headroom-adaptive tone mapping. Future updates to this specification may add new metadata to the smpte_st_2094_50_application_info metadata bitstream. If these changes are done in a backwards-compatible manner, then the minimum_application_version will be kept unchanged.
A parser encountering an unrecognized minimum_application_version shall ignore the entire smpte_st_2094_50_application_info metadata bitstream. The minimum_application_version syntax element shall be 0 in this version of the specification.
| smpte_st_2094_50_application_info() { | Type |
|---|---|
| application_version | u(3) |
| minimum_application_version | u(3) |
| reserved_zero | u(2) |
| smpte_st_2094_50_color_volume_transform() | |
| } |
Table C.2 presents the syntax for specifying the ColorVolumeTransform metadata group.
| smpte_st_2094_50_color_volume_transform() { | Type |
|---|---|
| has_custom_hdr_reference_white_flag | u(1) |
| has_adaptive_tone_map_flag | u(1) |
| reserved_zero | u(6) |
| if (has_custom_hdr_reference_white_flag == 1) { | |
| hdr_reference_white | u(16) |
| } | |
| if (has_adaptive_tone_map_flag == 1) { | |
| smpte_st_2094_50_adaptive_tone_map() | |
| } | |
| } |
Table C.3 presents the syntax for specifying the HeadroomAdaptiveToneMap metadata group.
| smpte_st_2094_50_adaptive_tone_map() { | Type |
|---|---|
| baseline_hdr_headroom | u(16) |
| use_reference_white_tone_mapping_flag | u(1) |
| if (use_reference_white_tone_mapping_flag == 0) { | |
| num_alternate_images | u(3) |
| gain_application_space_chromaticities_mode | u(2) |
| has_common_component_mix_params_flag | u(1) |
| has_common_curve_params_flag | u(1) |
| if (gain_application_space_chromaticities_mode == 3) { | |
| for (r = 0; r < 8; r++) { | |
| gain_application_space_chromaticities[r] | u(16) |
| } | |
| } | |
| for (a = 0; a < min(num_alternate_images, 4); a++) { | |
| alternate_hdr_headrooms[a] | u(16) |
| smpte_st_2094_50_component_mixing(a) | |
| smpte_st_2094_50_gain_curve(a) | |
| } | |
| } else { | |
| reserved_zero | u(7) |
| } | |
| } |
Table C.4 presents the syntax for specifying a ComponentMix metadata group.
| smpte_st_2094_50_component_mixing(a) { | Type |
|---|---|
| if (a == 0 || has_common_component_mix_params_flag == 0) { | |
| component_mixing_type[a] | u(2) |
| if (component_mixing_type[a] != 3) { | |
| reserved_zero | u(6) |
| } else { | |
| for (k = 0; k < 6; k++) { | |
| has_component_mixing_coefficient_flag[a][k] | u(1) |
| } | |
| for (k = 0; k < 6; k++) { | |
| if (has_component_mixing_coefficient_flag[a][k] == 1) { | |
| component_mixing_coefficient[a][k] | u(16) |
| } else { | |
| component_mixing_coefficient[a][k] = 0 | |
| } | |
| } | |
| } | |
| } else { | |
| component_mixing_type[a] = component_mixing_type[0] | |
| if (component_mixing_type[a] == 3) { | |
| for (k = 0; k < 6; k++) { | |
| component_mixing_coefficient[a][k] = component_mixing_coefficient[0][k] | |
| } | |
| } | |
| } | |
| } |
Table C.5 presents the syntax for specifying a GainCurve metadata group.
| smpte_st_2094_50_gain_curve(a) { | Type |
|---|---|
| if (a == 0 || has_common_curve_params_flag == 0) { | |
| gain_curve_num_control_points_minus_1[a] | u(5) |
| gain_curve_use_pchip_slope_flag[a] | u(1) |
| reserved_zero | u(2) |
| for (c = 0; c < gain_curve_num_control_points_minus_1[a] + 1; c++) { | |
| gain_curve_control_points_x[a][c] | u(16) |
| } | |
| } else { | |
| gain_curve_use_pchip_slope_flag[a] = gain_curve_use_pchip_slope_flag[0] | |
| gain_curve_num_control_points_minus_1[a] = gain_curve_num_control_points_minus_1[0] | |
| for (c = 0; c < gain_curve_num_control_points_minus_1[a] + 1; c++) { | |
| gain_curve_control_points_x[a][c] = gain_curve_control_points_x[0][c] | |
| } | |
| } | |
| for (c = 0; c < gain_curve_num_control_points_minus_1[a] + 1; c++) { | |
| gain_curve_control_points_y[a][c] | u(16) |
| } | |
| if (gain_curve_use_pchip_slope_flag[a] == 0) { | |
| for (c = 0; c < gain_curve_num_control_points_minus_1[a] + 1; c++) { | |
| gain_curve_control_points_theta[a][c] | u(16) |
| } | |
| } | |
| } |
This clause describes how to assign values to the metadata items described in 7.1, given the syntax elements from Clause C.2.
The ApplicationIdentifier metadata item shall be assigned the value 5.
The ApplicationVersion metadata item shall be assigned the value application_version.
The ProcessingWindow metadata group shall be assigned values as follows:
The ColorVolumeTransform metadata group shall be assigned values as specified in C.3.3.
If has_custom_hdr_reference_white_flag==0, then:
If has_custom_hdr_reference_white_flag==1, then:
If has_adaptive_tone_map_flag==0, then:
If has_adaptive_tone_map_flag==1, then:
The BaselineHdrHeadroom metadata item shall be assigned the value baseline_hdr_headroom.
If use_reference_white_tone_mapping_flag==0, then:
For each value NumAlternateImages:
The ColorGainFunction[a] metadata group shall be assigned values as follows:
If use_reference_white_tone_mapping_flag==1, then:
The GainApplicationChromaticities, metadata item shall be assigned a value as follows:
If gain_application_space_chromaticities_mode==0, then:
If gain_application_space_chromaticities_mode==1, then:
If gain_application_space_chromaticities_mode==2, then
If gain_application_space_chromaticities_mode==3, then:
The ComponentMix[a] metadata group shall be assigned values as follows:
If component_mixing_type[a]==0 then:
If component_mixing_type[a]==1 then:
If component_mixing_type[a]==2 then:
If component_mixing_type[a]==3 then:
The GainCurve[a] metadata group shall be assigned values as follows:
The GainCurveNumControlPoints[a] metadata item shall be assigned the value gain_curve_num_control_points_minus_1[a].
Let be the sign of the gain curve control point values. If baseline_hdr_headroom is less than alternate_hdr_headrooms[a] then let . Otherwise, let .
For each value GainCurveNumControlPoints[a]:
If gain_curve_use_pchip_slope_flag[a]==0, then:
For each value GainCurveNumControlPoints[a]:
If gain_curve_use_pchip_slope_flag[a]==1, then:
This clause specifies the metadata item values to assign in the HeadroomAdaptiveToneMap metadata group when the use_reference_white_tone_mapping_flag syntax element indicates that the parameters for headroom-adaptive tone mapping should be computed (as opposed to being specified).
Let BaselineHdrHeadroom.
The GainApplicationChromaticities, metadata item shall be assigned the value . This corresponds to the color primaries and white point specified in Table 3 of Recommendation ITU-R BT.2020-2.
If then:
If then:
The AlternateHdrHeadroom[1] metadata item shall be assigned the value as defined in Formula (C.1).
For NumAlternateImages, the ColorGainFunction[a] metadata group shall be assigned values as follows:
The ComponentMix[a] metadata group shall be assigned values as follows:
The GainCurve[a] metadata group shall be assigned values as follows:
Let .
The GainCurveNumControlPoints[a] metadata item shall be assigned the value .
Let be as defined in Formula (C.2).
Let .
The control point values are be defined by the functions , defined in Formula (C.6). These functions create a gain curve based on a knee in relative linear color space, which is be at the point .
For each value :
The functions define a parametric gain curve and its slope, given a knee point , a maximum point , and a highlight compression factor .
The gain curve is of the gain of a tone curve defined by a 2D BΓ©zier in relative linear color space, visualized on the left in Figure C.1. The control points of the BΓ©zier curve are , , and . The middle BΓ©zier control point is computed using the highlight compression factor in Formula (C.3).
The parametric BΓ©zier curve and its slope are given by the scalar functions defined in Formula (C.4).
The quadratic parameters and in Formula (C.4) are defined in Formula (C.5).
Finally, the functions are defined in Formula (C.6) by computing of the gain of the tone curve defined by the functions .
Figure C.1 illustrates the interpretation of the formulae in this clause. The BΓ©zier control points in Formula (C.3) and the resulting BΓ©zier curve from Formula (C.4) are displayed on the left. The resulting gain curve from Formula (C.6) is displayed on the right. The extrapolation behavior beyond the control points, specified by Formula (12), is indicated in both plots.
This clause specifies, for a given value of , the metadata item values to assign in the GainCurve[a] metadata group when the gain_curve_use_pchip_slope_flag syntax element indicates that the slopes of the th gain curve's control points should be computed (as opposed to being specified).
NOTE ββ The results of this computation are equivalent to the Piecewise Cubic Hermite Interpolation Package (PCHIP) algorithm described in DOI:10.1137/0905021.
Let GainCurveNumControlPoints[a]. For each , let GainCurveControlPointX[a][c] and let GainCurveControlPointY[a][c].
For , let be the length of the -th interval and let be the slope of the line connecting its control points.
Let be defined by Formula (C.7) if . Otherwise if then let and if then will not be used.
Let be defined by Formula (C.8) if . Otherwise if then let .
For , let be defined by Formula (C.9).
For each , GainCurveControlPointM[a][c] metadata item shall be assigned the value .