SMPTE ST 2094-50
Committee Draft
SMPTE Standard

Dynamic metadata for color volume transform β€” Application #5

Draft - Wed Nov 12 2025 21:41:53 GMT+0000 (Coordinated Universal Time)

Copyright Β© 2025, 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.


Warning: This document is an unpublished work under development and shall not be referred to as a SMPTE Standard, Recommended Practice, or Engineering Guideline. It is distributed for review and comment; distribution does not constitute publication. Recipients of this document are strongly encouraged to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of contentsπŸ”—

  1. Foreword
  2. Introduction
  3. 1 Scope
  4. 2 Conformance
  5. 3 Normative references
  6. 4 Terms and definitions
  7. 5 Mathematical notation
  8. 6 Data structures
    1. 6.1 Gain curve structure
      1. 6.1.1 Introduction
      2. 6.1.2 Parameter constraints
      3. 6.1.3 Function evaluation
    2. 6.2 Component mixing function structure
      1. 6.2.1 Introduction
      2. 6.2.2 Parameter constraints
      3. 6.2.3 Function evaluation
    3. 6.3 Color gain function structure
      1. 6.3.1 Introduction
      2. 6.3.2 Function evaluation
      3. 6.3.3 Zero color gain function
      4. 6.3.4 Visualization
    4. 6.4 Headroom-adaptive tone mapping structure
      1. 6.4.1 Introduction
      2. 6.4.2 Parameter constraints
      3. 6.4.3 Gain curve constraints (Informative)
      4. 6.4.4 Computation of alternate images
      5. 6.4.5 Computation of the headroom-adaptive tone map
      6. 6.4.6 Visualization
    5. 6.5 Color volume transform structure
      1. 6.5.1 Introduction
      2. 6.5.2 Parameter constraints
  9. 7 Application constraints
    1. 7.1 Metadata set
    2. 7.2 Metadata set constraints
  10. Annex A Computation of color volume transformation (Informative)
    1. A.1 Introduction
    2. A.2 Conversion to gain application color space
    3. A.3 Headroom-adaptive tone mapping in gain application color space
    4. A.4 Conversion from gain application color space to the target display
  11. Annex B Examples (Informative)
    1. B.1 Simple tone mapping
    2. B.2 Tone mapping with two alternate images
    3. B.3 Inverse tone mapping
    4. B.4 No tone mapping (projection or clamping)
  12. Annex C Binary encoding (Normative)
    1. C.1 Introduction
    2. C.2 Syntax
      1. C.2.1 Application syntax
      2. C.2.2 Color volume transform syntax
      3. C.2.3 Adaptive tone mapping syntax
      4. C.2.4 Component mixing syntax
      5. C.2.5 Gain curve syntax
    3. C.3 Semantics
      1. C.3.1 Introduction
      2. C.3.2 Application semantics
      3. C.3.3 Color volume transform semantics
      4. C.3.4 Adaptive tone mapping semantics
      5. C.3.5 Gain application color space chromaticity semantics
      6. C.3.6 Component mixing semantics
      7. C.3.7 Gain curve semantics
      8. C.3.8 Reference white adaptive tone mapping computation
      9. C.3.9 Piecewise cubic hermite interpolation package slope computation
  13. Annex D ITU-T T.35 carriage (Normative)
    1. D.1 Introduction
    2. D.2 Syntax
    3. D.3 Semantics
  14. Bibliography

ForewordπŸ”—

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.

IntroductionπŸ”—

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.

Figure 1 β€” Composition of multiple sources of content on a target display characterized by its high dynamic range headroom.

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.

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 a HDR headroom equal to a specified targeted HDR headroom parameter, as described in 6.4. 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 log2 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.

1 ScopeπŸ”—

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 an headroom-adaptive tone mapping algorithm, and the mathematical definition of that headroom-adaptive tone mapping algorithm.

2 ConformanceπŸ”—

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.

3 Normative referencesπŸ”—

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.

4 Terms and definitionsπŸ”—

For the purposes of this document, the following terms and definitions apply:

high dynamic range reference white
HDR reference white
HDR signal level that would typically result from a 100% Lambertian reflector placed at the centre of interest within a scene under controlled lighting
[SOURCE: ISO 21496-1:2025]
Note 1 to entry: This is commonly referred to as diffuse white in the HDR content.
Note 2 to entry: The HDR reference white can be used as an anchor for HDR and SDR content compositing. The HDR reference white is the HDR luminance level typically reached by nominal peak of SDR in display light (after the EOTF is applied along with a scaling factor).
Note 3 to entry: See also Section 2.1 and Table 1 of Report ITU-R BT.2408-8.
relative linear color space
representation of the output linear light levels in the range R3 where the color value [1,1,1] represents HDR reference white
Note 1 to entry: The floating-point signal representation in Table 10 of Recommendation ITU-R BT.2100-3 is a relative linear color space.
high dynamic range headroom
HDR headroom
ratio of maximum content light level of an image to its HDR reference white luminance, expressed as a log2 value
Note 1 to entry: For example, for an image with the HDR reference white at 203 cd/m2, and the maximum content light level equal to 1624 cd/m2, the HDR headroom would be log2⁑(1624203), or 3. This means 3 stops of HDR headroom beyond HDR reference white.
Note 2 to entry: This is analogous to the HDR headroom from Clause 3.6 of ISO 21496-1:2025.
baseline image
data structure that contains pixels and image-related data of the input image essence
Note 1 to entry: This is analogous to baseline image from Clause 3.2 of ISO 21496-1:2025.
baseline high dynamic range headroom
HDR headroom of the baseline image
Note 1 to entry: When the targeted HDR headroom parameter equals the baseline HDR headroom value, the headroom-adaptive tone mapping does not alter the baseline image.
Note 2 to entry: This is analogous to the baseline high dynamic range headroom from Clause 5.2.6 of ISO 21496-1:2025.
targeted high dynamic range headroom
HDR headroom of the image resulting from performing the headroom-adaptive tone map transform on the baseline image
headroom-adaptive tone map
image transform algorithm that takes as a parameter a targeted HDR headroom and, when applied to the baseline image, will produce an image with HDR headroom equal to the targeted HDR headroom
Note 1 to entry: The algorithm described in Clause 6.3 of ISO 21496-1:2025 is an example of another algorithm that can be used to produce an image with HDR headroom equal to a targeted HDR headroom using per pixel metadata.
color gain function
function that maps a color value, in the gain application color space, to a per-component log2 gain
gain application color space
relative linear color space in which the color gain function is sampled and in which the resulting gain is applied
Note 1 to entry: This is analogous to the gain map application space from Clause 3.4 of ISO 21496-1:2025.
alternate image
data structure that contains pixels obtained by applying the associated color gain function to the baseline image
Note 1 to entry: This is analogous to alternate image from Clause 3.1 of ISO 21496-1:2025.
alternate high dynamic range headroom
HDR headroom of an alternate image
Note 1 to entry: This is analogous to the alternate high dynamic range headroom from Clause 5.2.7 of ISO 21496-1:2025.

5 Mathematical notationπŸ”—

The symbol R represents the set of all real numbers.

The symbol Z represents the set of all integers numbers.

The expression ZN represents the set of integers {0,...,Nβˆ’1}.

The expression [a,b] represents the interval from a to b including both endpoints.

The expression (a,b) represents the interval from a to b excluding both endpoints.

6 Data structuresπŸ”—

6.1 Gain curve structureπŸ”—

6.1.1 IntroductionπŸ”—

A gain curve structure defines a function GainCurve:R→R.

A gain curve structure is parameterized by:

  • an integer Ncp number of control points
  • real values xi, yi, and mi for i∈ZNcp representing input, output, and slope of the control points

6.1.2 Parameter constraintsπŸ”—

The value of Ncp shall be greater than or equal to 1 and less than or equal to 32.

For i∈ZNcp, the value of xi shall be in the interval [0,64].

For i∈ZNcp, the value of yi shall be in the interval [βˆ’12,12].

For i∈ZNcpβˆ’1 it shall be the case that xi≀xi+1. If it is the case that xi=xi+1 then it shall also be the case that yi=yi+1.

6.1.3 Function evaluationπŸ”—

This clause describes the evaluation of the function GainCurve, given an input parameter x∈R.

For i∈ZNcpβˆ’1, let fi:[xi,xi+1]β†’R be the ith component of the gain curve, as defined in Formula (1).

fi(x)=c3Γ—t3+c2Γ—t2+c1Γ—t+c0where m^i=(xi+1βˆ’xi)Γ—mim^i+1=(xi+1βˆ’xi)Γ—mi+1c3=2yi+m^iβˆ’2yi+1+m^i+1c2=βˆ’3yi+3yi+1βˆ’2m^iβˆ’m^i+1c1=m^ic0=yit=(xβˆ’xi)/(xi+1βˆ’xi) (1)

The function GainCurve shall be equivalent to the definition in Formula (2).

GainCurve(x)={y0:x<x0yi:there exists i∈ZNcp such that x=xifi(x):there exists i∈ZNcpβˆ’1 such that xi<x<xi+1yNcpβˆ’1+log2⁑(xNcpβˆ’1x):xNcpβˆ’1≀x (2)

6.2 Component mixing function structureπŸ”—

6.2.1 IntroductionπŸ”—

A component mixing function structure defines a function ComponentMixing:R3β†’R3.

A component mixing function structure is parameterized by:

  • a real value kred representing the weighting of the red color component
  • a real value kgreen representing the weighting of the green color component
  • a real value kblue representing the weighting of the blue color component
  • a real value kmax representing the weighting of the maximum color component
  • a real value kmin representing the weighting of the minimum color component
  • a real value kcomponent representing the weighting of each color component

NOTE 1 —⁠ The ComponentMixing function is constructed such that for any x∈R, there exists a y∈R such that ComponentMixing([x,x,x])=[y,y,y]. This means that, when applied to color values, ComponentMixing will map 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.

6.2.2 Parameter constraintsπŸ”—

The values of kred, kgreen, kblue, kmax, kmin, and kcomponent shall be in the interval [0,1].

It shall be the case that kred+kgreen+kblue+kmax+kmin+kcomponent=1.

6.2.3 Function evaluationπŸ”—

This clause describes the evaluation of the function ComponentMixing, given an input parameter C=[cr,cg,cb]∈R3.

Let fcommon:R3β†’R be the part of the component mixing function that is common to all components. It shall be equivalent to the definition in Formula (3).

fcommon(C)=crΓ—kred+cgΓ—kgreen+cbΓ—kblue+max(cr,cg,cb)Γ—kmax+min(cr,cg,cb)Γ—kmin (3)

The function ComponentMixing shall be equivalent to the definition in Formula (4).

ComponentMixing(C)=[crΓ—kcomponent+fcommon(C)cgΓ—kcomponent+fcommon(C)cbΓ—kcomponent+fcommon(C)] (4)

NOTE —⁠ If the parameter kcomponent is equal to zero then all three components of ComponentMixing(C) will be equal.

6.3 Color gain function structureπŸ”—

6.3.1 IntroductionπŸ”—

A color gain function structure defines a color gain function Gain:R3β†’R3.

A color gain function structure is parameterized by:

NOTE —⁠ The resulting color gain function is equivalent to an adaptive gain curve from ICC Adaptive Gain Curve.

6.3.2 Function evaluationπŸ”—

This clause describes the evaluation of the function Gain, given an input parameter C∈R3.

Let M=[mr,mg,mb]∈R3 be the component mixing function evaluated at C, as defined in Formula (5)

M=[mrmgmb]=ComponentMixing(C) (5)

The function Gain shall be equivalent to the definition in Formula (6).

Gain(C)=[GainCurve(mr)GainCurve(mg)GainCurve(mb)] (6)

NOTE —⁠ If it is the case that all components of M are equal then the function GainCurve needs to be evaluated only once.

6.3.3 Zero color gain functionπŸ”—

The zero color gain function shall equal the color gain function defined in Formula (7).

Gain(C)=[0,0,0] (7)

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.

6.3.4 VisualizationπŸ”—

Figure 2 provides a visualization of the evaluation of the Gain function as described in 6.3.2.

Figure 2 β€” Visualization of the evaluation of the color gain function. Each arrow represents an individual color component.

6.4 Headroom-adaptive tone mapping structureπŸ”—

6.4.1 IntroductionπŸ”—

An headroom-adaptive tone map structure defines a function ToneMap:R3Γ—Rβ‰₯0β†’R3 which takes as parameters an input color C∈R3 in the gain application color space and a targeted HDR headroom Htarget, and returns a tone mapped color.

NOTE —⁠ The function ToneMap 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:

6.4.2 Parameter constraintsπŸ”—

The value of Hbaseline shall be in the interval [0,6].

The value of Nalt shall be greater than or equal to 0 and less than or equal to 4.

For i∈ZNalt, the value of Halt,i shall be in the interval [0,6].

For i∈ZNalt it shall be the case that Halt,iβ‰ Hbaseline.

For i∈ZNaltβˆ’1 it shall be the case that Halt,i<Halt,i+1.

The length of the vectors Ο‡red, Ο‡green, Ο‡blue, and Ο‡white shall be 2.

The values of the components of the vectors Ο‡red, Ο‡green, Ο‡blue, and Ο‡white shall be in the interval [0,1].

6.4.3 Gain curve constraints (Informative)πŸ”—

This clause is informative.

This clause lists constraints that are useful for achieving coherent headroom-adaptive tone mapping behavior but are not normatively required. Implementations can adjust metadata items so that they satisfy these constraints.

For i∈ZNalt, let GainCurvei be the function defined by the gain curve structure parameter to Gainalt,i.

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 will preferably be mapped to values equal to that alternate HDR headroom. This is accomplished if for each i∈ZNalt the equality in Formula (8) is true.

GainCurvei(2Hbaseline)=log2⁑(2Halt,i2Hbaseline)=Halt,iβˆ’Hbaseline (8)

Tone mapping to a targeted HDR headroom lower than the baseline HDR headroom will preferably only decrease the tone mapped result, and tone mapping to a targeted HDR headroom greater than the baseline HDR headroom will preferably only increase the tone mapped result. In symbols, this is accomplished if it is the case that for i∈ZNalt for all x∈R, if Halt,i<Hbaseline then GainCurvei(x)≀0 and if Halt,i>Hbaseline then GainCurvei(x)β‰₯0.

As the targeted HDR headroom of tone mapping increases, the tone mapped result will preferably only increase. In symbols, this is accomplished if it is the case that for i∈ZNaltβˆ’1 for all x∈R, GainCurvei(x)≀GainCurvei+1(x).

The tone mapping curves will preferably be monotonically increasing. In symbols, this is accomplished if it is the case that for i∈ZNalt, the function f(x)=xΓ—2GainCurvei(x) is monotonically increasing.

6.4.4 Computation of alternate imagesπŸ”—

When tone mapping to a targeted HDR headroom that is equal to an alternate HDR headroom the result of tone mapping will be the corresponding alternate image. In symbols, for any i∈ZNalt, the function ToneMap shall satisfy the equality in Formula (9).

ToneMap(C,Halt,i)=CΓ—2Gainalt,i(C) (9)

The equality in Formula (9) is satisfied by the function defined in Formula (13).

6.4.5 Computation of the headroom-adaptive tone mapπŸ”—

This clause describes the evaluation of the function ToneMap given an input color C∈R3 in the gain application color space and a targeted HDR headroom Htarget∈Rβ‰₯0.

Create a new list of HDR headrooms by inserting the baseline HDR headroom Hbaseline into the list of alternate HDR headrooms Halt,0,…,Halt,Naltβˆ’1 in its sorted position. Let N=Nalt+1 be the length of this new list and let H0,…,HNβˆ’1 be the list. Let Gain0,…,GainNβˆ’1 be the list Gainalt,0,…,Gainalt,Nβˆ’1 with the zero color gain function inserted at the position where Hbaseline was inserted.

NOTE —⁠

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 Hbaseline is inserted at the end of the list can be seen in Figure B.1. A visualization of an example in which Hbaseline is inserted at the beginning of the list can be seen in Figure B.3. A visualization of an example in which Hbaseline is the only entry in the list (because Nalt=0) can be seen in Figure B.4.

Let G∈R3 be the per-component gain in log2 space. This is computed as a weighted combination of color gain functions evaluated at C. The weighting depends on the value of Htarget parameter.

  • If there exists a value i such that Hi=clamp(Htarget,H0,HNβˆ’1) then G shall be equivalent to the result of the definition in Formula (10).

    G=Gaini(C) (10)
  • Otherwise, there must exist exactly one value i∈ZNβˆ’1 such that Hi<Htarget<Hi+1.

    Let wi and wi+1 be the weights of the i-th and i+1-th color gain functions. These weights shall be computed as defined in Formula (11).

    wi=Htargetβˆ’Hi+1Hiβˆ’Hi+1wi+1=Htargetβˆ’HiHi+1βˆ’Hi=1βˆ’wi (11)

    The value of G shall be equivalent to the result of the definition in Formula (12).

    G=wiΓ—Gaini(C)+wi+1Γ—Gaini+1(C) (12)

The headroom-adaptive tone mapping function shall be equivalent to the definition in Formula (13).

ToneMap(C,Htarget)=CΓ—2G (13)

6.4.6 VisualizationπŸ”—

Figure 3 provides a visualization of the computation of an alternate image as described in 6.4.4.

Figure 3 β€” Computation of the i-th alternate image

Figure 4 provides a visualization of the evaluation of the ToneMap function as described in 6.4.5.

Figure 4 β€” Headroom-adaptive tone map computation

6.5 Color volume transform structureπŸ”—

6.5.1 IntroductionπŸ”—

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:

6.5.2 Parameter constraintsπŸ”—

The value of Lwhite shall be in the interval (0,10000].

7 Application constraintsπŸ”—

7.1 Metadata setπŸ”—

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 which shall include at most one the following metadata items:

The HeadroomAdaptiveToneMap 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:

7.2 Metadata set constraintsπŸ”—

This clause specifies the constraints on the metadata set from 7.1, and defines the association between the 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.

Thee 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.5.1, and are subject to the constraints listed in 6.5.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.4.1, and are subject to the constraints listed in 6.4.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.2.1, and are subject to the constraints listed in 6.2.2.

The GainCurve[a] metadata group specifies a gain curve 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.

Annex A
Computation of color volume transformation (Informative)πŸ”—

A.1 IntroductionπŸ”—

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.

Figure A.1 β€” The generalized color volume transform model

The individual stages of Figure A.1 correspond to Figure A.2, followed by Figure 4, followed by Figure A.3.

A.2 Conversion to gain application color spaceπŸ”—

This clause describes the computation of the function ToGainApplicationSpace:R3β†’R3, 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 1 and the black signal is 0. It is also assumed to have transfer characteristics that determine its non-linear encoding and opto-optical transfer function. This corresponds a normalized Rβ€²,Gβ€²,Bβ€² 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. Very 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, Yβ€²,CBβ€²,CRβ€² or I,CT,CP).

The computation is visualized in Figure A.2, and represents the "Convert to Gain Application Color Space" block of Figure A.1.

Figure A.2 β€” Conversion of an input signal to gain application color space processing block. The intermediate results of the RGB components of luminance and color value in the relative linear color space with the signal's color primaries are shown at the bottom of the figure.

Let E∈R3 be this input signal value.

NOTE 1 —⁠ Components of E can be outside of the [0,1] 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 Lwhite be the value of the HDR reference white parameter specified by the HdrReferenceWhite metadata item.

Let Eotf:R3β†’R3 be the electro-optical transfer function which converts an input signal value to RGB components of luminance in cd/m2.

NOTE 3 —⁠ When refering 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 Eotf for some common video signal transfer characteristics is as follows.

Let Minput,gain 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 ToGainApplicationSpace can be computed as as defined in Formula (A.3).

ToGainApplicationSpace(E)=Minput,gainΓ—1LwhiteΓ—Eotf(E) (A.3)

A.3 Headroom-adaptive tone mapping in gain application color spaceπŸ”—

This clause describes the computation of the headroom-adaptive tone mapping algorithm.

Let Htarget∈Rβ‰₯0 be the targeted HDR headroom that characterizes the capabilities of target display. This can be computed as log2 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.

Let ToneMap:R3Γ—Rβ‰₯0β†’R3 be defined by the headroom-adaptive tone map structure parameter specified by the HeadroomAdaptiveToneMap metadata group.

Let C∈R3 be a color from the baseline image, in the gain application color space. Let T∈R3 be the color resulting from applying the headroom-adaptive tone mapping algorithm to that color. The value of T can be computed as defined in Formula (A.4).

T=ToneMap(C,Htarget) (A.4)

A.4 Conversion from gain application color space to the target displayπŸ”—

This clause describes the computation of the function ToTargetColorVolume:R3β†’R3, given a tone mapped color T∈R3 in the gain application color space. The computation is visualized in Figure A.3, and represents the "Convert to Target Color Volume" block of Figure A.1.

Figure A.3 β€” Conversion to target display color volume processing block

Let Lwhite,target be the luminance at which HDR reference white will be displayed. Let Mgain,target be the 3x3 matrix that converts color primaries from the gain application color space primaries to the target color volume color primaries.

The function ToTargetColorVolume can be computed as defined in Formula (A.5).

ToTargetColorVolume(T)=Lwhite,targetΓ—Mgain,targetΓ—T (A.5)

Displays can perform more complicated transformations from the gain application color space to the target display, for example, to adjust for non-reference ambient viewing conditions. That topic is out of the scope of this specification.

NOTE —⁠ Any colors that do not fit in the targeted display color volume (any colors with components greater than 2Htarget 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.

Annex B
Examples (Informative)πŸ”—

B.1 Simple tone mappingπŸ”—

Figure B.1 illustrates the color gain functions and associated tone mapping functions of an headroom-adaptive tone mapping with a baseline high dynamic range headroom Hbaseline=log2⁑(4)=2, and a standard dynamic range alternate image with Halt,0=log2⁑(1)=0.

On the left side of Figure B.1 are the underlying color gain functions in the log2 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 2Hbaseline=4 to 2Haltr,0=1, 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 Htarget=log2⁑(2)=1 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 w0=w1=12. The resulting adapted tone mapping curve on the right maps 2Hbaseline=4 to 2Htarget=2.

Figure B.1 β€” Simple headroom-adaptive tone mapping from high dynamic range to standard dynamic range

B.2 Tone mapping with two alternate imagesπŸ”—

Figure B.2 illustrates a slightly more complicated example of headroom-adaptive tone mapping with an additional alternate image with Halt,1=log2⁑(2)=1. This new alternate image indicates that, when tone mapping to a targeted HDR headroom of 1, 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 Htarget=log2⁑(1.5)β‰ˆ0.58 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 w0β‰ˆ0.42 and w1β‰ˆ0.58. The resulting adapted tone mapping curve on the right maps 2Hbaseline=4 to 2Htarget=1.5.

Figure B.2 β€” Headroom-adaptive tone mapping from high dynamic range to standard dynamic range with two alternate images

B.3 Inverse tone mappingπŸ”—

Figure B.3 illustrates an example of inverse tone mapping with a standard dynamic range baseline image with Hbaseline=log2⁑(1)=0, and a high dynamic range alternate image with Halt,0=log2⁑(4)=2.

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 H1=Halt,0 because Hbaseline is inserted at the beginning of the merged list of HDR headrooms in 6.4.5.

Adaptation to the targeted HDR headroom of Htarget=log2⁑(2)=1 is indicated using a dotted line, as was also done in the example in Clause B.1.

Figure B.3 β€” Headroom-adaptive tone mapping from standard dynamic range to high dynamic range

B.4 No tone mapping (projection or clamping)πŸ”—

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.4.5, this means that Nalt=0 and therefore N=1. The only entry in the constructed list of HDR headrooms will be H0=Hbaseline, and the only entry in the constructed list of color gain functions will be G0 which will equal the zero color gain function. The value of G will be set by Formula (10) and will be G=[0,0,0]. Finally, the function ToneMap as defined in Formula (13) will evaluate to be the identity, as worked out in Formula (B.1).

ToneMap(C,Htarget)=CΓ—2G=CΓ—20=C (B.1)

This means that the image resulting from the headroom-adaptive tone mapping in the color volume transform step in Clause A.3 will be the unchanged baseline image. After this, the image will be converted to the target display as described in Clause A.4, and the resulting image will be projected to the targeted color volume, as described in Clause A.4, Note. The result of this operation will be 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.4 β€” Headroom-adaptive tone mapping from high dynamic range to standard dynamic range with zero alternate images

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.

Figure B.5 β€” Projection of the baseline image to target color volumes with various targeted HDR headrooms

Annex C
Binary encoding (Normative)πŸ”—

C.1 IntroductionπŸ”—

The metadata for Application #5 shall 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.

C.2 SyntaxπŸ”—

C.2.1 Application syntaxπŸ”—

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.

Table C.1 β€” Application #5 syntax structure
smpte_st_2094_50_application_info() { Type
  application_versionu(8)
  smpte_st_2094_50_color_volume_transform()
}

C.2.2 Color volume transform syntaxπŸ”—

Table C.2 presents the syntax for specifying the ColorVolumeTransform metadata group.

Table C.2 β€” Color volume transform syntax structure
smpte_st_2094_50_color_volume_transform() { Type
  has_custom_hdr_reference_white_flagu(1)
  has_adaptive_tone_map_flagu(1)
  reserved_zerou(6)
  if (has_custom_hdr_reference_white_flag == 1) {
    hdr_reference_whiteu(16)
  }
  if (has_adaptive_tone_map_flag == 1) {
    smpte_st_2094_50_adaptive_tone_map()
  }
}

C.2.3 Adaptive tone mapping syntaxπŸ”—

Table C.3 presents the syntax for specifying the HeadroomAdaptiveToneMap metadata group.

Table C.3 β€” Headroom-adaptive tone map structure syntax
smpte_st_2094_50_adaptive_tone_map() { Type
  baseline_hdr_headroomu(16)
  use_reference_white_tone_mapping_flagu(1)
  if (use_reference_white_tone_mapping_flag == 0) {
    num_alternate_imagesu(3)
    gain_application_space_chromaticities_flagu(2)
    has_common_component_mix_params_flagu(1)
    has_common_curve_params_flagu(1)
    if (gain_application_space_chromaticities_flag == 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_zerou(7)
  }
}

C.2.4 Component mixing syntaxπŸ”—

Table C.4 presents the syntax for specifying a ComponentMix metadata group.

Table C.4 β€” Component mixing function structure syntax
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_zerou(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]
      }
    }
  }
}

C.2.5 Gain curve syntaxπŸ”—

Table C.5 presents the syntax for specifying a GainCurve metadata group.

Table C.5 β€” Gain curve structure syntax
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_zerou(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)
    }
  }
}

C.3 SemanticsπŸ”—

C.3.1 IntroductionπŸ”—

This clause describes how to assign values to the metadata items described in 7.1 given the syntax elements from Clause C.2.

C.3.2 Application semanticsπŸ”—

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 WindowNumber metadadata item shall be assigned the value 0.
  • The UpperLeftCorner metadadata item shall be assigned the value [0,0].
  • The LowerRightCorner metadadata item shall be assigned the value of the size of the input image essence in pixels.

The ColorVolumeTransform metadata group shall be assigned values as specified in C.3.3.

C.3.3 Color volume transform semanticsπŸ”—

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:

C.3.4 Adaptive tone mapping semanticsπŸ”—

The BaselineHdrHeadroom metadata item shall be assigned the value min(baseline_hdr_headroom,60000)Γ—110000.

If use_reference_white_tone_mapping_flag==0, then:

If use_reference_white_tone_mapping_flag==1, then:

C.3.5 Gain application color space chromaticity semanticsπŸ”—

The GainApplicationChromaticities, metadata item shall be assigned a value as follows.

If gain_application_space_chromaticities_flag==0, then:

If gain_application_space_chromaticities_flag==1, then:

  • The GainApplicationChromaticities metadata item shall be assigned the value [0.68,0.32,0.265,0.69,0.15,0.06,0.3127,0.329]
  • This corresponds to the color primaries specified in Table 1 of SMPTE ST 2113:2018 and the D65 white point specified in Clause 6.2.

If gain_application_space_chromaticities_flag==2, then

If gain_application_space_chromaticities_flag==3, then:

C.3.6 Component mixing semanticsπŸ”—

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:

C.3.7 Gain curve semanticsπŸ”—

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]+1.

For each value c∈{0,...,GainCurveNumControlPoints[a]βˆ’1):

If gain_curve_use_pchip_slope_flag[a]==0, then:

If gain_curve_use_pchip_slope_flag[a]==1, then:

C.3.8 Reference white adaptive tone mapping computationπŸ”—

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).

NOTE —⁠ The results of this computation are equivalent to the Reference White Tone Mapping Operator described in ISO/TC 22028-5:2023.

Let Hbaseline=BaselineHdrHeadroom.

The GainApplicationChromaticities, metadata item shall be assigned the value [0.708,0.292,0.17,0.797,0.131,0.046,0.3127,0.329]. This corresponds to the color primaries and white point specified in Table 3 of Recommendation ITU-R BT.2020-2.

If Hbaseline=0 then:

If Hbaseline>0 then:

For a∈{0,...,NumAlternateImagesβˆ’1}, the ColorGainFunction[a] metadata group shall be assigned values as follows.

The functions Gx,Gy,Gm define a parametric gain curve and its slope, given a knee point [xknee,yknee]∈R2, a maximum point [xmax,ymax]∈R2, and a highlight compression factor κ∈[0,1].

The gain curve is log2 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 [xknee,yknee], [xmid,ymid], and [xmax,ymax]. The middle BΓ©zier control point [xmid,ymid] is computed using the highlight compression factor ΞΊ in Formula (C.3).

xmid=(1βˆ’ΞΊ)Γ—xknee+ΞΊΓ—(xkneeΓ—ymaxyknee)ymid=(1βˆ’ΞΊ)Γ—yknee+ΞΊΓ—ymax (C.3)

The parametric BΓ©zier curve and its slope are given by the scalar functions x,y,m:[0,1]β†’R defined in Formula (C.4).

x(t)=axΓ—t2+bxΓ—t+cxy(t)=ayΓ—t2+byΓ—t+cym(t)=2Γ—ayΓ—t+by2Γ—axΓ—t+bx (C.4)

The quadratic parameters ax,bx,cx∈R and ay,by,cy∈R in Formula (C.4) are defined in Formula (C.5).

ax=xkneeβˆ’2Γ—xmid+xmaxbx=2Γ—xmidβˆ’2Γ—xkneecx=xkneeay=ykneeβˆ’2Γ—ymid+ymaxby=2Γ—ymidβˆ’2Γ—ykneecy=yknee (C.5)

Finally, the functions Gx,Gy,Gm are defined in Formula (C.6) by computing log2 of the gain of the tone curve defined by the functions x,y,m.

Gx(t,xknee,yknee,xmax,ymax,ΞΊ)=x(t)Gy(t,xknee,yknee,xmax,ymax,ΞΊ)=log2⁑(y(t)x(t))Gm(t,xknee,yknee,xmax,ymax,ΞΊ)=x(t)Γ—m(t)βˆ’y(t)log⁑(2)Γ—x(t)Γ—y(t) (C.6)

Figure C.1 illustrates the interpretation of the equations 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 (2), is indicated in both plots.

Figure C.1 β€” Illustration of Formula (C.6) and its components Formula (C.3) and Formula (C.4) with example parameters xknee=1, yknee=0.8, xmax=4, ymax=2, and ΞΊ=0.65.

C.3.9 Piecewise cubic hermite interpolation package slope computationπŸ”—

This clause specifies, for a given value of a, 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 ath 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 Ncp=GainCurveNumControlPoints[a]. For each i∈ZNcp, let xi=GainCurveControlPointX[a][c] and let yi=GainCurveControlPointY[a][c].

For i∈ZNcpβˆ’1, let hi=xi+1βˆ’xi be the length of the i-th interval and let si=yi+1βˆ’yixi+1βˆ’xi be the slope of the line connecting its control points.

Let m0 be defined by Formula (C.7) if Ncpβ‰₯3. Otherwise if Ncp=2 then let m0=s0 and if Ncp=1 then m0 will not be used.

m0=(2Γ—h0+h1)Γ—s0βˆ’h0Γ—s1h0+h1 (C.7)

Let mNcpβˆ’1 be defined by Formula (C.8) if Ncpβ‰₯3. Otherwise if Ncp=2 then let mNcpβˆ’1=s0.

mNcpβˆ’1=(2Γ—hNcpβˆ’2+hNcpβˆ’3)Γ—sNcpβˆ’2βˆ’hNcpβˆ’2Γ—sNcpβˆ’3hNcpβˆ’2+hNcpβˆ’3 (C.8)

For i∈{1,...,Ncpβˆ’2}, let mi be defined by Formula (C.9).

mi={0:sign(siβˆ’1)β‰ sign(si)3Γ—(hiβˆ’1+hi)Γ—siβˆ’1Γ—si(2Γ—hiβˆ’1+hi)Γ—siβˆ’1+(hiβˆ’1+2Γ—hi)Γ—si:otherwise (C.9)

For each c∈ZNcp, GainCurveControlPointM[a][c] metadata item shall be assigned the value mc.

Annex D
ITU-T T.35 carriage (Normative)πŸ”—

D.1 IntroductionπŸ”—

This clause describes carriage of Application #5 metadata using the Recommendation ITU-T T.35 mechanism.

For Application #5, the Recommendation ITU-T T.35 country code is 0xB5 (United States), the terminal provider code is 0x0090 (SMPTE), and the terminal provider oriented code is 0x0001.

D.2 SyntaxπŸ”—

Table D.1 presents the Recommendation ITU-T T.35 metadata syntax structure, truncated to include only the syntax required for Application #5.

Table D.1 β€” Recommendation ITU-T T.35 metadata syntax
metadata_itu_t_t35() { Type
  itu_t_t35_country_codeu(8)
  if (itu_t_t35_country_code == 0xB5) {
    itu_t_t35_us_terminal_provider_codeu(16)
    if (itu_t_t35_us_terminal_provider_code == 0x0090) {
      itu_t_t35_smpte_terminal_provider_oriented_codeu(16)
      if (itu_t_t35_smpte_terminal_provider_oriented_code == 0x0001) {
        smpte_st_2094_50_application_info()
      } else {
        // Handling of other terminal provider oriented codes
      }
    } else {
      // Handling of other terminal provider codes
    }
  } else {
    // Handling of other country codes
  }
}

D.3 SemanticsπŸ”—

The itu_t_t35_country_code syntax element specifies the first byte of the Recommendation ITU-T T.35 country code.

The itu_t_t35_us_terminal_provider_code syntax element specifies the Recommendation ITU-T T.35 terminal provider code for the United States country.

The itu_t_t35_smpte_terminal_provider_oriented_code a syntax element specifies the Recommendation ITU-T T.35 terminal provider oriented code for the SMPTE terminal provider.

BibliographyπŸ”—