Guided transitions between two different dynamic ranges with new metadata

Abstract

A method comprising: obtaining (601) input video data and interoperability metadata within an input dynamic range; converting (602) the input video data into output video data in an output dynamic range using the interoperability metadata; wherein the interoperability metadata includes at least one of information indicating an HDR diffused white value, information indicating an SDR diffused white value, information indicating an HDR narrow range value, information indicating an HDR narrow full range value, information indicating an SDR narrow full range maximum value, and information indicating a narrow full range minimum value.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority from European application No. 23305273.7 filed on March 2, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0002] At least one of the present embodiments generally relates to the field of high dynamic range (HDR) video production, and more particularly to methods, devices, and apparatus that implement a signaling mechanism that allows identification of appropriate HDR to SDR or SDR to HDR conversion in a single-master production and distribution system. The signaling mechanism allows interoperability of different equipment and techniques in a real-world workflow. Background Art

[0003] Recent advances in display technology allow for an extended dynamic range of colour, brightness and contrast in displayed images.The term image here refers to image content which may be, for example, a video or a still picture or image.

[0004] High dynamic range video (HDR video) describes video with a greater dynamic range than standard dynamic range video (SDR video). HDR video involves capture, production, content / encoding, and display. HDR capture and display devices are capable of brighter whites and darker blacks. To accommodate this, the HDR encoding standard allows for higher maximum brightness and uses at least 10 bits of dynamic range (compared to 8 bits for non-professional SDR video and 10 bits for professional SDR video) to maintain accuracy across this extended range.

[0005] HDR production is a new field, and there will be a transition phase during which both HDR content and SDR content will coexist. During this coexistence phase, the same live content will be produced in both HDR and SDR versions simultaneously. The user can then display either the HDR or SDR version of the content, depending on their preference or ability.

[0006] The current trend in the content production industry is to: first, produce HDR content and then use automated tools to automatically derive SDR content from the HDR content (this is called a single-master production and distribution workflow); and second, apply a controlled and secure scheme for HDR production to avoid delivering poor HDR or SDR content to users.

[0007] In this respect, some recommendations have been introduced by the ITU-R document "Report ITU-R BT.2408-3, Guidance for operational practices in HDR television production, 07 / 2019" (hereinafter referred to as BT.2408-3 report). One important recommendation introduced in the BT.2408-3 report is the constraint of the HDR diffuse white set to a fixed value equal to "203" nits. This constraint allows the use of a fixed 3D-LUT (Look-Up Table) to achieve SDR to HDR conversion (i.e. inverse tone mapping (ITM)) and HDR to SDR conversion (tone mapping (TM)). Different static LUT solutions are available on the market. These static LUTs have different characteristics (i.e. they use different diffuse white values, different maximum specular HDR values, different TM and ITM curves, different source and target transfer functions and they have different extended range usage). The use of these static LUTs makes the system static, i.e. the conversion (ITM or TM) is fixed and not adapted to the dynamic characteristics of the content. Dynamic conversion offers a solution to cope with this issue based on the use of a configurable and dynamic HDR diffuse white level for both HDR to SDR (tone mapping) and SDR to HDR (inverse tone mapping) conversions.

[0008] Real workflows are made with many different equipment from different providers. There is nothing preventing different providers to implement different solutions in their equipment, such as different static 3D-LUT or dynamic solutions. However, equipment implementing different solutions are generally not interoperable.

[0009] It is desirable to overcome the above drawbacks.

[0010] It is particularly desirable to propose a mechanism that allows to ensure the selection of the appropriate conversion and that allows to ensure the interoperability of different equipment and technologies in real workflows. SUMMARY

[0011] In a first aspect, one or more of the embodiments herein provide a method comprising: obtaining input video data in an input dynamic range; obtaining interoperability metadata; transmitting the input video data and the interoperability metadata; wherein the interoperability metadata comprises at least one of information representative of an HDR diffuse white value, information representative of an SDR diffuse white value, information representative of an HDR narrow range value, information representative of an HDR narrow full range value, information representative of an SDR narrow full range maximum value and information representative of a narrow full range minimum value.

[0012] In embodiments, the input dynamic range is HDR or SDR.

[0013] In embodiments, the interoperability metadata is transmitted using an auxiliary channel of an SDI interface.

[0014] In embodiments, the interoperability metadata is embedded in SL-HDR1 metadata.

[0015] In embodiments, the interoperability metadata is transmitted using SEI messages.

[0016] In a second aspect, one or more of the embodiments herein provide a method comprising: obtaining input video data in an input dynamic range and interoperability metadata; converting the input video data to output video data in an output dynamic range using the interoperability metadata; wherein the interoperability metadata comprises at least one of information representative of an HDR diffuse white value, information representative of an SDR diffuse white value, information representative of an HDR narrow range value, information representative of an HDR narrow full range value, information representative of an SDR narrow full range maximum value, and information representative of a narrow full range minimum value.

[0017] In embodiments, the input dynamic range is HDR or SDR.

[0018] In embodiments, the interoperability metadata is used to define a tone mapping process that allows converting the input video data from the input dynamic range to the output dynamic range in response to the input dynamic range being HDR and the output dynamic range being SDR; and the interoperability metadata is used to define an inverse tone mapping process that allows converting the input video data from the input dynamic range to the output dynamic range in response to the input dynamic range being SDR and the output dynamic range being HDR.

[0019] In embodiments, the interoperability metadata is received using an auxiliary channel of an SDI interface.

[0020] In embodiments, the interoperability metadata is embedded in SL-HDR1 metadata.

[0021] In embodiments, the interoperability metadata is transmitted using SEI messages.

[0022] In a third aspect, one or more of the embodiments herein provide an apparatus comprising electronic circuitry configured to: obtain input video data in an input dynamic range; obtain interoperability metadata; transmit the input video data and the interoperability metadata; wherein the interoperability metadata comprises at least one of information representative of an HDR diffuse white value, information representative of an SDR diffuse white value, information representative of an HDR narrow range value, information representative of an HDR narrow full range value, information representative of an SDR narrow full range maximum value, and information representative of a narrow full range minimum value.

[0023] In embodiments, the input dynamic range is HDR or SDR.

[0024] In embodiments, the interoperability metadata is transmitted using an auxiliary channel of an SDI interface.

[0025] In embodiments, the interoperability metadata is embedded in SL-HDR1 metadata.

[0026] In embodiments, wherein the interoperability metadata is transmitted using SEI messages.

[0027] In a fourth aspect, one or more of the embodiments herein provide an apparatus comprising electronic circuitry configured to: obtain input video data in an input dynamic range and interoperability metadata; convert the input video data to output video data in an output dynamic range using the interoperability metadata; wherein the interoperability metadata comprises at least one of information representative of an HDR diffuse white value, information representative of an SDR diffuse white value, information representative of an HDR narrow range value, information representative of an HDR narrow full range value, information representative of an SDR narrow full range maximum value, and information representative of a narrow full range minimum value.

[0028] In embodiments, the input dynamic range is HDR or SDR.

[0029] In embodiments, the interoperability metadata is used to define a tone mapping process that allows conversion of the input video data from the input dynamic range to the output dynamic range in response to the input dynamic range being HDR and the output dynamic range being SDR, and the interoperability metadata is used to define an inverse tone mapping process that allows conversion of the input video data from the input dynamic range to the output dynamic range in response to the input dynamic range being SDR and the output dynamic range being HDR.

[0030] In embodiments, the interoperability metadata is received using an auxiliary channel of an SDI interface.

[0031] In embodiments, the interoperability metadata is embedded in SL-HDR1 metadata.

[0032] In embodiments, the interoperability metadata is transmitted using SEI messages.

[0033] In a fifth aspect, one or more of the embodiments herein provides a non-transitory information storage medium storing program code instructions for implementing a method according to the first or second aspect.

[0034] In a sixth aspect, one or more of the embodiments herein provides a signal comprising interoperability metadata, the interoperability metadata comprising at least one of information representative of an HDR diffuse white value, information representative of an SDR diffuse white value, information representative of an HDR narrow range value, information representative of an HDR narrow full range value, information representative of an SDR narrow full range maximum value, and information representative of a narrow full range minimum value.

[0035] In a seventh aspect, one or more of the embodiments herein provides a computer program comprising program code instructions for implementing a method according to the first or second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0036] Figure 1A illustrates a scale of luminance values in which a diffuse white occurs; Figure 1B illustrates a split of the scale of luminance values when the diffuse white is fixed to "203" nits; Figure 1C schematically illustrates the context of various embodiments; Figure 2 illustrates a single master HDR / SDR workflow; Figure 3A illustrates an example of a luminance ITM curve that complies with the characteristics provided by the interoperability metadata; Figure 3B illustrates an example of a luminance TM curve that complies with the characteristics provided by the interoperability metadata; Figure 4 illustrates a single master HDR / SDR workflow according to an embodiment; Figure 5 illustrates an example of a process performed by a video source according to an embodiment; Figure 6 illustrates an example process performed by equipment responsible for converting video data from a first dynamic range to a second dynamic range according to an embodiment; Figure 7 Examples of a process for introducing interoperability metadata in SL-HDR1 metadata are provided; Figure 8A An example of a hardware architecture of a processing module capable of implementing various aspects and embodiments is schematically illustrated; Figure 8B A block diagram illustrating an example of a first system in which various aspects and embodiments are implemented; and Figure 8C A block diagram illustrating an example of a second system in which various aspects and embodiments are implemented. DETAILED DESCRIPTION

[0037] In the following, we introduce several concepts used in various embodiments.

[0038] Diffuse white: As mentioned previously, the BT.2408-3 report proposes some recommendations and in particular proposes a constraint on the diffuse white. The diffuse white is defined in the BT.2408-3 report as “a white provided by a card through minimization of specular highlights and minimization of spectral power absorption ratio, becoming a spectral gray, not only a photometric gray, approximating a perfect reflecting diffuser”. The “perfect reflecting diffuser” is defined as “an ideal isotropic non-fluorescent diffuser having a spectral radiance factor equal to 1 at every wavelength of interest”.

[0039] In other words, the diffuse white is the luminance level of the video signal that separates the following two items: • a scene with all details, corresponding to a luminance level below the diffuse white; • speculars: very bright pixels, generally close to white and with very few details, corresponding to a luminance level above the diffuse white level.

[0040] Figure 1A A scale illustrating the luminance values in which the diffuse white occurs is illustrated. As can be seen, the diffuse white separates the set of all possible luminance values in two parts.

[0041] The diffuse white concept is valid for HDR signals and for SDR signals.

[0042] The BT.2408-3 report specifies that the HDR diffuse white is equal to “203” nits.

[0043] However, the “203” nits constraint is only a recommendation and many content producers disagree with this recommendation. Indeed, an HDR diffuse white equal to “203” nits brings a major problem: the HDR content is constrained, i.e. for a typical “1000” nits HDR content, only a small amount of HDR luminance range [0-203 nits] is dedicated to the details of the scene, while the largest part of the HDR luminance range [203-1000 nits] is reserved for speculars that do not bring details.

[0044] Figure 1B The separation of the scale of luminance values is illustrated when the diffuse white is fixed to "203" nits.

[0045] One of the reasons for this limitation is the need for controlled and "very safe" live HDR content production. In addition, this limitation has the following advantages: • The implementation of the conversion from HDR to SDR (i.e. Tone Mapping (TM)) is simpler since the HDR diffuse white defined at "203" nits needs to be mapped to the SDR diffuse white which is generally defined between 90% and 100% SDR (i.e. between 90 and 100 nits). Therefore, the tone mapping can be implemented using a very basic static 3D-LUT. • The implementation of the conversion from SDR to HDR (i.e. Inverse Tone Mapping (ITM)) is also simpler for the same reason and the inverse tone mapping can also be implemented with a very basic static 3D-LUT.

[0046] However, this ratio between the luminance values assigned to the details of the scene and the luminance values assigned to the specular highlights caused by the diffuse white at "203" nits makes the resulting HDR image very dull and unattractive.

[0047] Narrow range and narrow full range: As described in the Recommendations ITU-R BT.709-6 (Parameter values for the HDTV standards for production and international program exchange, 06 / 2015) and ITU-R BT.2100-2 (Image parameter values for high dynamic range television for use in production and international program exchange, 07 / 2018), typical video signals are transmitted using the YCbCr representation also named YUV representation.

[0048] In this representation, the quantization levels are defined from the lowest value to the highest value. For example, when using a "10" bit quantization, the luminance values are defined between the lowest value "64" (black) and the highest value "940" (white), and the chrominance values are defined between the lowest value "64" and the highest value "960". These allowed ranges are commonly named legal range or narrow range or normal range. In the following, we will use the term narrow range (NR).

[0049] However, the recommendations ITU-R BT.709-6 and ITU-R BT.2100-2 also state that the video data can take values from "4" to "1019".

[0050] The EBU R 103 (Recommendation EBU R103, Video signal tolerance in digital video systems version 3.0, 05 / 2020) recommendation gives some explanations about why a certain tolerance is needed when generating YCbCr signals, and recommends not to exceed the range [20-984].

[0051] However, some implementations do not follow the range [20-984] recommended by the EBU R103 recommendation, and utilize the range [4-1019] or any range starting with values in the range [4-63] and ending with values in the range [941-1019].

[0052] The combination of the ranges [4-63] and [941-1019] (or [961-1019]) with the NR range [64-940] (or [64-960]) is named in the following narrow full range (NFR).

[0053] The range [4-63] is named in the following black out color.

[0054] The range [941-1019] (or [941-1019]) is named in the following super white color.

[0055] Typically, 3D-LUT implementations use these black out color and super white color ranges. For example, the super white color range is typically used to carry an additional dynamic range that can be useful when performing SDR to HDR or HDR to SDR conversion.

[0056] Figure 1C An example context in which various embodiments are implemented is illustrated.

[0057] In Figure 1C The live production system 20 communicates with a main central control system 21. The live production system 20 provides simultaneously an HDR version and an SDR version of the same live content.

[0058] The main central control system 21 then encodes the same or enriched versions in these SDR and HDR versions and provides these encoded versions to the devices 22A and 22B. In embodiments, the main central control system 21 uses an AVC ((ISO / CEI 14496-10 / ITU-T H.264) encoder, a HEVC (ISO / IEC 23008-2 - MPEG-H Part 2, High Efficiency Video Coding / ITU-T H.265) encoder, a VVC (ISO / IEC 23090-3 - MPEG-I, Versatile Video Coding / ITU-T H.266) encoder or any other encoder to encode the HDR and SDR versions.

[0059] The devices 22A and 22B are display devices such as a PC, a TV, a smartphone, a tablet or a head-mounted display or devices connected to display devices such as a set-top box. The device 22A with HDR capabilities receives the encoded HDR version. The device 22B with only SDR capabilities receives the encoded SDR version.

[0060] Figure 2 A single master HDR / SDR workflow is illustrated. Figure 2 Details are provided regarding the live production system 20 and the main central control system 21.

[0061] The live production system 20 comprises two sources: an HDR source 200 and an SDR source 201. Each source comprises at least one of a camera, a playback system or a system generating graphics. The SDR source 201 is connected to a plurality of ITM tools: • one ITM tool 202A (ITM1) for SDR camera output up-conversion to HDR; • one ITM tool 202B (ITM2) for SDR playback content up-conversion to HDR; and • one ITM tool 202C (ITM3) for SDR graphics (e.g. score insertion) content up-conversion to HDR.

[0062] The HDR content routing and switching system 203 ingests a plurality of HDR inputs either from the HDR source 200 or from the SDR source 201 and then generates a plurality of HDR outputs.

[0063] From these HDR outputs, a plurality of TM tools are used: • a TM tool 204B (TM1) for generating a predictive SDR output used by a shader operator that rates the quality of the generated SDR content sent to the main central control system 21. • TM tool 204A (TM2) for generating SDRs to be provided to the main central control system 21.

[0064] The main central control system 21 comprises an HDR main control system 212 and an SDR main control system 213. The HDR and SDR main control systems are in charge of distributing SDR / HDR content. In the example of Fig. 1, the main central control system 21 comprises a source 210 generating advertisements in SDR and an ITM tool 211 converting advertisements from SDR to HDR. The HDR main control system 212 receives these advertisements converted to HDR and mixes them with HDR content it receives. The HDR (or SDR) main control system 212 (or 213) encodes the HDR (or SDR data) it receives or that results from the mixing of HDR (or SDR) data it receives with other data. For example, SDR and HDR data are encoded by an AVC encoder, a HEVC encoder, a VVC encoder or any other encoder. Figure 2

[0065] As can be seen in Fig. 1, the HDR content can originate from a native HDR source 200. Since the HDR content needs to be converted to SDR, there is currently no way for the TM tool 204B (TM1) and / or the TM tool 204A (TM2) to know the characteristics of the native HDR source, such as the HDR diffuse white value, the NFR value and at which SDR diffuse white the HDR diffuse white is mapped. Figure 2

[0066] If the TM tool (204A or 204B) uses a specific static 3D-LUT, the only solution now is to make sure that the HDR source 200 is correctly configured to produce a video signal compatible with this specific 3D-LUT. However, there is nothing preventing the HDR source provider to configure the HDR source 200 differently in a way that is no longer compatible with this specific 3D-LUT. Similarly, there is nothing preventing the TM tool configurator to select a different static 3D-LUT that is not compatible with the HDR source 200. Indeed, different static 3D-LUT solutions are available on the market. The following static 3D-LUT solutions can be mentioned: ​​BBC LUTs (Release Notes for HLG Format Conversion LUTs v1.5, BBC Research, 05 / 2021, http: / / downloads.bbc.co.uk / rd / pubs / papers / HDR / BBC_HDRTV_HLG_LUT_Release_Notes_v1-5.pdf): The current version 1.5 of the BBC LUT solution describes 20 different 3D-LUTs for different uses / configurations. NBCU LUTs (NBCUniversal Single-Master Broadcast Production and Distribution Recommendations#NBCU-Rec-UHD-HDR-01.13, September 23, 2022, https: / / github.com / digitaltvguy / NBCUniversal-UHD-HDR-SDR-Single-Master-Production-Workflow-Recommendation-LUTs): The current version 1.13 of the NBCU LUT solution describes 5 different 3D-LUTs for different uses / configurations. HBS has recently designed its own HDR to SDR 3D-LUT for the World Cup in Qatar (see https: / / www.sportsvideo.org / 2022 / 12 / 07 / live-from-the-fifa-world-cup-hbs-ceo-dan-miodownik-cto-christian-gobbel-reflect-on-efforts-to-date / ).

[0067] All of these static LUTs are different, namely: HDR and SDR diffuse white values ​​are different; Due to the different use of SDR maximum NFR and HDR maximum NFR values, the maximum specular HDR value is different; The NFR usage of these LUTs is different; The HDR values ​​mapped to the maximum SDRNR values ​​are different; Tone mapping and inverse tone mapping curves are different; Source and target transfer functions can be different (HDR transfer function can be HLG or PQ).

[0068] Table TAB1 represents values of SDR and HDR diffuse white, SDR Max NR, HDR values from SDR Max NR, SDR Max NFR and HDR values from SDR Max NFR: Table TAB1 This plurality of static 3D LUTs creates a risk of misconfiguration.

[0069] If the tone mapping tool uses a dynamic solution, thanks to its dynamic nature, it can adapt to the content. However, the conversion can not be optimal, this is due to the fact that the tone mapping tool lacks information such as HDR and SDR diffuse white values and NFR usage. Knowing this information would allow the dynamic tone mapping tool to produce a more optimal HDR to SDR conversion.

[0070] Figure 2 Another aspect is that the output of the HDR master control system 212 is a mixture of the main HDR video content with native SDR content. This situation is common in the case of diffuse of live HDR content. For example, during the diffuse of content representing a live video event, logos, scores and advertisements are mixed into the main HDR video representing a live sports event. As in the example of Figure 2 The added content can be SDR and thus needs to be converted into HDR before being mixed with the main HDR video content. Since the resulting mixed HDR content is very likely to be converted into SDR, a new constraint appears: the SDR content resulting from the so-called SDR-HDR-SDR roundtrip conversion of these added content (i.e. ITM conversion followed by TM conversion (for SDR delivery)) must be identical to the original SDR content. When a content producer generates HDR content from original SDR content but wants the SDR content generated from this HDR content to be identical to the original SDR content for any reason, the same SDR-HDR-SDR roundtrip constraint exists.

[0071] In the context where static LUTs and / or dynamic solutions are not controlled, the risk of misconfiguration is high and thus the risk of not being able to respect the SDR-HDR-SDR roundtrip constraint is high.

[0072] Therefore, there is a need to find solutions allowing interoperability between equipment of a single master HDR / SDR workflow. Therefore, these solutions would allow respecting the SDR-HDR-SDR roundtrip constraint.

[0073] In the following, various embodiments are proposed based on the use of additional metadata called interoperability metadata.

[0074] In embodiments, the interoperability metadata comprises six information: • HDR diffuse white value HDR_DW: HDR_DW gives the HDR diffuse white value for the HDR content. An HDR pixel with a luminance above HDR_DW is called a specular in the HDR content. In case of a potential subsequent SDR to HDR conversion, it indicates on which HDR diffuse white value the SDR diffuse white (defined below) value should be mapped. It can be expressed in units of nits or any coded representation related to values in nits. • SDR diffuse white value SDR_DW: SDR_DW gives the SDR diffuse white value for the expected subsequent HDR to SDR (TM) conversion. An SDR pixel with a luminance above SDR_DW is considered as a specular in the SDR content resulting from the TM conversion. It indicates on which SDR diffuse white value the HDR diffuse white value HDR_DW should be mapped. It can be expressed in units of nits or any coded representation related to values in nits. If the HDR content is native HDR content from an HDR source and if SDR_DW is not present in the metadata, the TM tool is free to choose the SDR diffuse white value. If the HDR content originates from an SDR source that has been converted to HDR, SDR_DW can indicate either of the following two items: o the SDR diffuse white value of the SDR content that has been mapped on the HDR diffuse white value HDR_DW during the ITM conversion. It allows the subsequent TM conversion to map the HDR diffuse white value to the SDR diffuse white value SDR_DW. This information thus allows to meet the SDR-HDR-SDR roundtrip constraint, o the SDR diffuse white value to which the HDR diffuse white value HDR_DW should be mapped by the subsequent TM conversion. This SDR diffuse white value SDR_DW can be different from the source SDR diffuse white value since it is for example in the NBCU LUT (the source SDR diffuse white is "100" nits and the output SDR diffuse white is "86" nits). • HDR narrow range (NR) value HDR_NR: HDR_NR gives the HDR luminance value that needs to be mapped on the narrow range maximum luminance value of the SDR content (i.e. "940" expressed in "10" bits codewords) during the subsequent TM conversion. • HDR narrow full range value HDR_NFR: HDR_NFR gives the HDR maximum luminance value that needs to be mapped to the narrow full range maximum luminance value SDR_NFR_MAX of the SDR content during the subsequent TM conversion. • SDR narrow full range maximum value SDR_NFR_MAX: SDR_NFR_MAX gives the highest luminance allowed value used in the upper part of the SDR narrow full range, corresponding to the HDR_NFR value of the corresponding HDR content. The value can be expressed by an "8" bit, a "10" bit or a "12" bit value or by a percentage of the narrow range. For example, the value is equal to "1019" expressed in 10 bits (or 109% expressed in percentage of the narrow range) for the SDI / Total Video Signal range and the value is equal to "984" expressed in "10" bit code word (or 105% expressed in percentage of the narrow range) according to each EBU R103 recommendation. SDR_NFR_MAX cannot be lower than the maximum narrow range value, i.e. "940" expressed in 10 bits (or 100%). • Narrow full range minimum value NFR_MIN: NFR_MIN gives the lowest allowed value used in the lower part of the narrow full range. The value can be expressed by an "8" bit, a "10" bit or a "12" bit value or by a percentage of the narrow range. For example, the value is equal to "4" expressed in "10" bit code word (or -6.84% expressed in percentage of the narrow range) for the SDI / Total Video Signal range and the value is equal to "20" expressed in "10" bit code word (or -5% expressed in percentage of the narrow range) according to each EBU R103 recommendation. The value cannot be higher than the minimum narrow range value, i.e. "64" expressed in "10" bit (or 0%).

[0075] The interoperability metadata (and in particular the "6" information) allows to define the characteristics that must be respected by the TM and ITM curves (implemented in any static conversion in the form of e.g. 3D-LUTs or in any dynamic solution) that must be used in a single master HDR / SDR workflow by TM and ITM tools.

[0076] Figure 3A An example of a luminance ITM curve that complies with the characteristics provided by the interoperability metadata is illustrated.

[0077] In the example of Figure 3A : • The NFR_MIN value of the input SDR content (e.g. equal to "4" for "10" bit code word) is mapped to the same NFR_MIN value of the output HDR content (i.e. "4" for "10" bit code word in this example). • The narrow range minimum value of the input SDR content ("64" for "10" bit code word) is mapped to the same narrow range minimum value of the output HDR content ("64" for "10" bit code word). • The SDR_DW value of the input SDR content is mapped to the HDR_DW value of the output HDR content. • The narrow range maximum of the input SDR content (940 for a "10" bit code word) is mapped on the HDR_NR value of the output HDR content. • The SDR_NFR_MAX value of the input SDR content (e.g. equal to 1019 for a "10" bit code word) is mapped to the HDR_NFR value of the output HDR content.

[0078] Figure 3B An example of a luminance TM curve that complies with the characteristics provided by the interoperability metadata is illustrated.

[0079] In the example of Figure 3B : • The NFR_MIN value of the input HDR content (e.g. equal to 4 for a "10" bit code word) is mapped to the same NFR_MIN value of the output SDR content (i.e. 4 for a "10" bit code word in this example). • The narrow range minimum of the input HDR content (64 for a "10" bit code word) is mapped to the same narrow range minimum of the output SDR content (64 for a "10" bit code word). • The HDR_DW value of the input HDR content is mapped to the SDR_DW value of the output SDR content. • The HDR_NR value of the input HDR content is mapped to the narrow range maximum of the output SDR content (940 for a "10" bit code word). • The HDR_NFR value of the input HDR is mapped to the SDR_NFR_MAX value of the output SDR content (e.g. equal to 1019 for a "10" bit code word).

[0080] Any static 3D-LUT can be characterized using interoperability metadata. As an example, in table TAB2, we map the "6" information provided by the interoperability metadata on the values of an existing 3D-LUT whose characterization in table TAB1 represents the SDR and HDR diffuse white, the SDR maximum NR, the HDR value from the SDR maximum NR, the SDR maximum NFR and the HDR value from the SDR maximum NFR. Table TAB2

[0081] More generally, any static converter can be characterized using interoperability metadata. Similarly, any dynamic converter that is able to manage these interoperability metadata can produce dynamic conversion curves that are compatible with the interoperability metadata.

[0082] Figure 4 Fig. illustrates a single master HDR / SDR workflow in which interoperability metadata (IMD) is used. Figure 2 Fig. illustrates a single master HDR / SDR workflow in which interoperability metadata (IMD) is used.

[0083] As can be seen in Fig. 1, each equipment generating HDR data emits interoperability metadata along the HDR data. The equipment generating HDR data comprises the HDR source 200, the ITM tools 202A, 202B and 202C and 211. Figure 4

[0084] In embodiments, the interoperability metadata is provided to the TM tools 204A and 204B to guide the TM process applied to the HDR data to generate SDR data.

[0085] In embodiments, the interoperability metadata is distributed along the HDR data by the HDR master control system 212. In this embodiment, the interoperability metadata is used to guide the TM process applied on the distributed HDR data.

[0086] In embodiments, it is also possible to associate interoperability metadata with SDR data. In this case, the interoperability metadata is generated by the equipment generating SDR data. The equipment generating SDR data is for example the SDR source 201, the TM tools 204A and 204B. In the example of Fig. 2, when associated with SDR data, the interoperability metadata can be distributed along the SDR data by the SDR master control system 213. In this case, the interoperability metadata is used to guide the ITM process applied on the distributed SDR data. Figure 4

[0087] As can be seen in the example of table TAB2, the interoperability metadata can allow to characterize the TM process or the ITM process.

[0088] The interoperability metadata characterizing the TM process allows for example the TM tool to directly identify which TM process (i.e. which TM curve or which 3D LUT defining the TM curve) is applicable when emitted along the HDR data.

[0089] The interoperability metadata characterizing the ITM process allows for example the TM tool to identify the nature of the HDR data or which ITM process (i.e. which ITM curve or which 3D LUT defining the ITM curve) was applied to obtain the HDR data when emitted along the HDR data. In this case, from the interoperability metadata, the TM tool can determine a TM process compatible with the nature of the HDR data or the ITM process applied to obtain the HDR data. In some embodiments, the determined TM process can ensure SDR-HDR-SDR roundtrip constraints.

[0090] ​​When emitted along SDR data, the interoperability metadata characterizing the ITM process allows, for example, the ITM tool to directly identify which ITM process (i.e., which ITM curve or which 3D LUT defining the ITM curve) is applicable.

[0091] When emitted along SDR data, the interoperability metadata characterizing the TM process allows, for example, the ITM tool to identify the characteristics of the SDR data or which TM process (i.e., which TM curve or which 3D LUT defining the TM curve) was applied to obtain the SDR data. In this case, from the interoperability metadata, the ITM tool can determine an ITM process that is compatible with the characteristics of the SDR data or the TM process that was applied to obtain the SDR data. Again, the determined TM process can ensure the SDR-HDR-SDR roundtrip constraint.

[0092] Figure 5 Figures illustrate an example of a process performed by a video source, according to an embodiment.

[0093] Figure 5 The process of Fig. 1 is performed by a processing module of a video source. The video source is, for example, the HDR source 200, the SDR source 201, the ITM tool 202A, 202B, 202C, or 211, or the TM tool 204A or 204B.

[0094] In step 501, the processing module obtains input video data in an input dynamic range. The input dynamic range can be HDR or SDR.

[0095] In step 502, the processing module obtains interoperability metadata. The interoperability metadata can characterize the input video data in the input dynamic range or the output video data to be obtained from the input video data after conversion from the input dynamic range to an output dynamic range. When the input dynamic range is HDR, the output dynamic range is SDR. Otherwise, when the input dynamic range is SDR, the output dynamic range is HDR.

[0096] In step 503, the processing module emits the input video data and the interoperability metadata. The input video data and the interoperability metadata are, for example, emitted from the HDR source 200 to the TM tools 204A and 204B. In another example, the input video data and the interoperability metadata are emitted from the HDR source 200 to the client equipment via the HDR master control system 212.

[0097] Figure 6 Figures illustrate an example process performed by equipment responsible for converting video data from a first dynamic range to a second dynamic range, according to an embodiment.

[0098] Figure 6The process is performed by a processing module of equipment responsible for converting video data from a first dynamic range to a second dynamic range. The equipment is, for example, the TM tool 204A or 204B.

[0099] In step 601, the processing module obtains input video data and interoperability metadata in an input dynamic range. Again, the input dynamic range can be HDR or SDR. In an example, the input video data and interoperability metadata are received by the TM tool 204A or 204B from the HDR source 200 or from the ITM tool 202A or 202B or 202C. In another example, the input video data is received by the equipment from the HDR source 200 or from the ITM tool 202A or 202B or 202C via the HDR control system 212 or via the SDR master control system 213.

[0100] In step 602, the processing module converts the input video data into output video data in a second dynamic range using the interoperability metadata. Again, when the input dynamic range is HDR, the output dynamic range is SDR, and when the input dynamic range is SDR, the output dynamic range is HDR.

[0101] An adapted solution is needed to transport HDR or SDR data together with interoperability metadata between modules of a production system, such as, for example, between the HDR source 200 or from the ITM tool 202A or 202B or 202C and the TM tools 204A and 204B of the live production system 20, or for distributing HDR or SDR data and interoperability metadata to external equipment after production (for example, via the master central control system 21). Typical production systems, such as the live production system 20, use SDI (Serial Digital Interface) interconnections following the suite of SMPTE standards for exchanging data inside the system. The auxiliary channels of the SDI interface allow to exchange additional information, such as metadata. For example, metadata can be exchanged using the vertical auxiliary channel (in the following, SDI VANC) as described in the standard SMPTE ST 2108-1 (SMPTE ST 2108-1:2018, HDR / WCG Metadata Packing and Signaling in the Vertical Ancillary Data Space, 10 / 2018). Interoperability metadata can also be exchanged using the same SDI-based mechanism.

[0102] The first solution for transmitting HDR or SDR data along with interoperability metadata is based on SL-HDR1. SL-HDR1 (ETSI TS 103 433-1 vl.4.1, High-Performance Single Layer High Dynamic Range (HDR) System for use in Consumer Electronics devices; Part 1: Directly Standard Dynamic Range (SDR) Compatible HDR System (SL-HDR1), 08 / 2021) is a standard allowing the representation of HDR content through an SDR signal with dynamic metadata. The SDR signal is produced from the tone mapping (TM) of the HDR content based on the application of a tone mapping tool of a tone mapping curve. The dynamic metadata represent the inverse tone mapping curve allowing the conversion of the SDR signal back to the HDR signal.

[0103] As described in sections A.2.2.2 and A.2.2.4 of SL-HDR1, if the flag sl_hdr_extension_present_flag is set to “1”, any information can be embedded in the SL-HDR1 metadata in the form of SL-HDR extension data bytes sl_hdr_extension_data_byte. In embodiments, this option of SL-HDR1 is used for the transmission of interoperability metadata.

[0104] Figure 7 An example of a process for introducing interoperability metadata in SL-HDR1 metadata is provided. The process is implemented by a processing module of a HDR source, such as the HDR source 200, or by an ITM tool, such as the ITM tools 202A, 202B, 202C or 211. The process is for example executed in step 503.

[0105] In step 701, the processing module sets the flag sl_hdr_extension_present_flag to 1 and the syntax element sl_hdr_extension_length to “12”. The syntax element sl_hdr_extension_length represents the byte length of the SL-HDR extension data bytes.

[0106] In step 702, the processing module signals the value of SDR diffuse white in nits, SDR_DW, on two bytes of the SL-HDR extension data bytes, sl_hdr_extension_data_byte[0] and sl_hdr_extension_data_byte[1], sl_hdr_extension_data_byte[0] being the least significant byte of a 16-bit integer value and sl_hdr_extension_data_byte[1] being the most significant byte of a 16-bit integer value.

[0107] In step 703, the processing module signals the value of HDR diffuse white in nits, HDR_DW, on two bytes of the SL-HDR extension data bytes, sl_hdr_extension_data_byte[2] and sl_hdr_extension_data_byte[3], sl_hdr_extension_data_byte[2] being the least significant byte of a “16”-bit integer value and sl_hdr_extension_data_byte[3] being the most significant byte of a “16”-bit integer value.

[0108] In step 704, the processing module signals the HDR narrow range value in nits, HDR_NR, on two bytes of the SL-HDR extension data bytes, sl_hdr_extension_data_byte[4] and sl_hdr_extension_data_byte[5], sl_hdr_extension_data_byte[4] being the least significant byte of a “16”-bit integer value and sl_hdr_extension_data_byte[5] being the most significant byte of a “16”-bit integer value.

[0109] In step 705, the processing module signals the HDR narrow full range value in nits, HDR_NFR, on two bytes of the SL-HDR extension data bytes, sl_hdr_extension_data_byte[6] and sl_hdr_extension_data_byte[7], sl_hdr_extension_data_byte[6] being the least significant byte of a “16”-bit integer value and sl_hdr_extension_data_byte[7] being the most significant byte of a “16”-bit integer value.

[0110] In step 706, the processing module signals the narrow full range minimum NFR_MIN on two bytes sl_hdr_extension_data_byte[8] and sl_hdr_extension_data_byte[9] in the SL-HDR extension data bytes, sl_hdr_extension_data_byte[8] being the least significant byte of a "16" bit integer value and sl_hdr_extension_data_byte[9] being the most significant byte of a "16" bit integer value. The signaled value NFR_MIN can be defined by convention to represent for example a "10" bit value. Thus, for a system managing signals with different bit depths such as 8 bit or 12 bit content, this 10 bit code word can be easily converted for 8 bit code words, 12 bit code words,....

[0111] In step 707, the processing module signals the SDR narrow full range maximum SDR_NFR_MAX on two bytes sl_hdr_extension_data_byte

[10] and sl_hdr_extension_data_byte

[11] in the SL-HDR extension data bytes, sl_hdr_extension_data_byte

[10] being the least significant byte of a "16" bit integer value and sl_hdr_extension_data_byte

[11] being the most significant byte of a "16" bit integer value. The signaled value SDR_NFR_MAX can be defined by convention to represent for example a 10 bit value. Thus, for a system managing signals with different bit depths such as 8 bit or 12 bit content, this 10 bit code word can be converted for 8 bit code words, 12 bit code words,....

[0112] If some metadata are already present in the SL-HDR extension data bytes, it is also possible to add the 6 new metadata before or after these already present metadata. Any other representation of the "6" information in the SL-HDR1 metadata is also possible, for example regarding less or more bytes for each information, non byte alignment, etc.

[0113] Another solution for transmitting video data together with interoperability metadata consists in transmitting the metadata in SEI messages.

[0114] Video compression standards such as VVC, HEVC and AVC define messages comprising metadata providing information about the video stream, called Supplemental Enhancement Information (SEI) messages. SEI messages are data containers or syntax structures associated with the video stream.

[0115] The SEI messages supply a solution for the transport of interoperability metadata. New SEI messages dedicated to the transport of interoperability metadata can be defined.

[0116] These SEI messages can be transported in the form of SDI VANC messages as defined in SMPTE ST 2108-1.

[0117] It can be noted that alternatively these SEI messages can be inserted in the transport stream along with the encoded video stream assigned by the main central control system.

[0118] As already mentioned before, there are many existing video equipment embedding HDR to SDR (TM) or SDR or HDR (TM) conversion. These conversions can be implemented using static 3D-LUTs or using dynamic solutions.

[0119] In this context, several scenarios of use of interoperability metadata are possible. Some different scenarios are provided hereafter.

[0120] 1st scenario: interoperability metadata match a static 3D-LUT known by the module in charge of the conversion.

[0121] When the "6" information contained in the interoperability metadata match a 3D-LUT known by the module in charge of the conversion, the selection of the 3D-LUT to apply is straightforward for the conversion module.

[0122] For example, if the single master HDR / SDR workflow uses HLG content and if the "6" information are as follows: • SDR_DW = 86 • HDR_DW = 203 • NFR_MIN = 4 • SDR_NFR_MAX = 1006 • HDR_NR = 294 • HDR_NFR = 1810, then the NBCU LUT 3 as described in table TAB2 is the appropriate selection.

[0123] 2nd scenario: interoperability metadata do not match any static 3D-LUT known by the module in charge of the conversion.

[0124] When the "6" information of the interoperability metadata do not match one static 3D-LUT known by the conversion module, the equipment determines which 3D-LUT will be the most appropriate. For this, many different algorithms can be defined. For example: • Decide based on HDR_DW value only, and select 3D-LUT corresponding to HDR diffuse white value closest to HDR_DW value; • Decide based on HDR_DW value only, and select 3D-LUT corresponding to HDR diffuse white value closest to but lower than HDR_DW value; • Decide based on HDR_DW value only, and select 3D-LUT corresponding to HDR diffuse white value closest to but higher than HDR_DW value; • Decide based on SDR_DW value only, and select 3D-LUT corresponding to SDR diffuse white value closest to SDR_DW value; • Decide based on SDR_DW value only, and select 3D-LUT corresponding to SDR diffuse white value closest to but lower than SDR_DW value; • Decide based on SDR_DW value only, and select 3D-LUT corresponding to SDR diffuse white value closest to but higher than SDR_DW value; • Decide based on both HDR_DW and SDR_DW values, and select 3D-LUT corresponding to HDR diffuse white and SDR diffuse white values closest to HDR_DW value and SDR_DW value; • Decide based on both HDR_DW and SDR_DW values, and select 3D-LUT corresponding to HDR diffuse white and SDR diffuse white values closest to but lower than HDR_DW and SDR_DW values; • Decide based on both HDR_DW and SDR_DW values, and select 3D-LUT corresponding to HDR and SDR diffuse white values closest to but higher than HDR_DW and SDR_DW values; • Decide based on any combination of "1" to "6" information, and select 3D-LUT for which combination of "1" to "6" information is closest to "1" to "6" characteristics characterizing the 3D-LUT.

[0125] The method used by the conversion module is not limited to the proposed method.

[0126] 3rd scenario: interoperability metadata used to emulate existing single master HDR / SDR workflow.

[0127] In a certain existing single-master HDR / SDR workflow (e.g., the workflow proposed by NBCU (see NBCUniversal Single-Master Broadcast Production and Distribution Recommendations # NBCU-Rec-UHD-HDR-01.13, September 23nd, 2022, https: / / github.com / digitaltvguy / NBCUniversal-UHD-HDR-SDR-Single-Master-Production-Workflow-Recommendation-LUTs)), it is recommended to use a specific static 3D-LUT for SDR-to-HDR conversion and HDR-to-SDR conversion.

[0128] For example, if the NCBU workflow is used in Figure 2 the ITM tools 202A, 202B and 202C use the ITM 3D-LUT NBCU LUT 1 (see table TAB2) and the TM tools 204A and 204B use the counterpart TM 3D-LUT NBCU LUT 3.

[0129] In generating the HDR content with the ITM 3D-LUT NBCU LUT 1, one possibility to ensure compatibility with the NCBU workflow is that the ITM tools populate the interoperability metadata with the SDR_DW, HDR_DW, NFR_MIN, SDR_NFR_MAX, HDR_NR and HDR_NFR values corresponding to the counterpart TM 3D-LUT NBCU LUT 3. Upon receiving the interoperability metadata, the TM tools 204A and 204B select the 3D-LUT specified by the interoperability metadata, i.e., they select the TM 3D-LUT NBCU LUT 3. The use of the interoperability metadata makes the selection of the appropriate TM 3D-LUT automatic and reliable.

[0130] 4th scenario: interoperability metadata for improved SDR-HDR-SDR roundtrip in single-master HDR / SDR workflow.

[0131] Although the SDR-HDR-SDR roundtrip is not guaranteed in the previous scenario, one purpose of the 4th scenario is to show how the interoperability metadata can be used to improve the SDR-HDR-SDR roundtrip. Again, let's take the example of the single master HDR / SDR workflow proposed by NBCU, in which the ITM 3D-LUT NBCU LUT 1 is used to generate the HDR content, in the 4th scenario, the ITM tool populates the interoperability metadata with the SDR_DW, HDR_DW, NFR_MIN, SDR_NFR_MAX, HDR_NR and HDR_NFR values corresponding to the ITM 3D-LUT NBCU LUT 1.

[0132] In this case, when the equipment (e.g. TM tools 204A and 204B) receives the HDR content along with the interoperability metadata corresponding to the ITM 3D-LUT NBCU LUT 1, it can select a newly defined TM 3D-LUT that perfectly matches the characteristics of the ITM 3D-LUT NBCU LUT 1. Therefore, this new TM 3D-LUT will allow a perfect SDR-HDR-SDR roundtrip.

[0133] 5th scenario: dynamic HDR to SDR converter configuration Let's consider that the equipment (e.g. TM tools 204A and 204B) is embedded with a dynamic tone mapping solution that is compatible with the interoperability metadata, i.e. it is able to produce a tone mapping curve as shown in Figure 3B

[0134] When the equipment receives the native HDR content along with the interoperability metadata, the equipment configures the dynamic solution with the "6" information, allowing the dynamic solution to deliver the appropriate TM conversion.

[0135] When the equipment receives the HDR content resulting from the ITM conversion along with the interoperability metadata describing the characteristics of the ITM conversion, the equipment configures the dynamic system with the "6" information, allowing the dynamic system to deliver the appropriate TM conversion, i.e. it is able to respect the SDR-HDR-SDR roundtrip constraint.

[0136] Whenever the values of the interoperability metadata change, from the native HDR content or from the HDR content resulting from the ITM conversion, the dynamic solution is always able to dynamically adapt to the new HDR content characteristics.

[0137] Figure 8A ​An example of a hardware architecture of a processing module 80 is schematically illustrated, the processing module 80 being comprised in the live production system 20, in a system or module comprised in the live production system 20, such as the ITM tools 202A, 202B and 202C or the TM tools 204B and 204A, in the main central control system 21, or in a system or module of the main central control system 21, such as the ITM tool 211, or in the equipment 22A and 22B. The processing module 80 comprises, connected by a communication bus 805: a processor or CPU (Central Processing Unit) 800, encompassing, as non-limiting examples, one or more microprocessors, general purpose computers, special purpose computers, and processors based on a multi-core architecture, as well as a Random Access Memory (RAM) 801, a Read Only Memory (ROM) 802, a storage unit 803, which can include non-volatile memory and / or volatile memory, including, but not limited to, Electrically Erasable Programmable Read-Only Memory (EEPROM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), flash, magnetic or optical disk drives or diskettes, and / or card readers such as SD (Secure Digital) card reader and / or Hard Disk Drive (HDD) and / or network accessible storage device, at least one communication interface 804 for exchanging data with other modules, devices, systems or equipment. The communication interface 804 can include, but is not limited to, a transceiver configured to transmit and to receive data on a communication network 81. The communication interface 804 can include, but is not limited to, a modem or a network card.

[0138] For example, the communication interface 804 enables the processing module 80, for example, with HDR or SDR data along with interoperability metadata.

[0139] The processor 80 is capable of executing instructions loaded into the RAM 801 from the ROM 802, from an external memory (not shown), from a storage medium or from a communication network. When the processing module 80 is powered on, the processor 800 is capable of reading instructions from the RAM 801 and executing them. These instructions form a computer program which enables, for example, the processor 800 of the HDR source 200, the ITM tools 202A, 202B and 202C and 211 to implement the method of Figure 5 and the processor 800 of the TM tools 204A and 204B to implement the method of Figure 6 .

[0140] All or some of the algorithms and steps of the processes can be implemented in software form by execution of an instruction set by a programmable machine such as a DSP (Digital Signal Processor) or a microcontroller, or in hardware form by a machine or a dedicated component such as an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit).

[0141] Figure 8C A block diagram illustrating an example of a system A corresponding to the device 22A or 22B in which various aspects and embodiments are implemented is shown.

[0142] The system A can be embodied as a device comprising various components or modules and configured to generate SDR or HDR content adapted to be displayed on an adapted display device. Examples of such a system include, but are not limited to, various electronic systems such as a personal computer, a laptop computer, a smartphone, a tablet, a TV or a set-top box. Individually or in combination, the components of the system A can be embodied in a single integrated circuit (IC), in multiple ICs, and / or in discrete components. For example, in at least one embodiment, the system A comprises one processing module 80 implementing the decoding of SDR or HDR content. In various embodiments, the system A is communicatively coupled to one or more other systems or other electronic devices via, for example, a communication bus or through dedicated input and / or output ports.

[0143] The input to the processing module 80 can be provided through various input modules as indicated in block 60. Such input modules include, but are not limited to: (i) a radio frequency (RF) module that receives RF signals transmitted over the air, for example, by a broadcaster; (ii) a component (COMP) input module (or a set of COMP input modules); (iii) a universal serial bus (USB) input module; and / or (iv) a high-definition multimedia interface (HDMI) input module. Figure 8C Other examples not shown in Fig. 6 include composite video.

[0144] In various embodiments, the input module of block 60 has associated corresponding input processing elements as known in the art. For example, the RF module can be associated with elements suitable for: (i) selecting a desired frequency (also known as selecting a signal or band-limiting a signal to a frequency band); (ii) down-converting the selected signal; (iii) again band-limiting to a narrower frequency band to select a signal frequency band that (for example) may be referred to as a channel in some embodiments; (iv) demodulating the down-converted and band-limited signal; (v) performing error correction; and (vi) demultiplexing to select a desired data packet stream. The RF module of various embodiments includes one or more elements for performing these functions, such as a frequency selector, a signal selector, a band limiter, a channel selector, a filter, a down-converter, a demodulator, an error corrector, and a demultiplexer. The RF portion can include a tuner that performs various of these functions, including, for example, down-converting the received signal to a lower frequency (for example, an intermediate frequency or a near-baseband frequency) or to baseband. Various embodiments rearrange the order of the above-described (and other) elements, remove some of these elements, and / or add other elements that perform similar or different functions. Adding elements can include inserting elements between existing elements, such as, for example, inserting an amplifier and an analog-to-digital converter. In various embodiments, the RF module includes an antenna.

[0145] In addition, the USB and / or HDMI modules may include corresponding interface processors for connecting System A to other electronic devices across the USB and / or HDMI connections. It should be understood that various aspects of input processing, such as Reed-Solomon error correction, may be implemented, for example, within a separate input processing IC or, if necessary, within processing module 80. Similarly, aspects of USB or HDMI interface processing may be implemented within a separate interface IC or, if necessary, within processing module 80. The demodulated, error-corrected, and demultiplexed stream is provided to processing module 80.

[0146] The various elements of system A can be provided within an integrated housing. Within the integrated housing, the various elements can be interconnected and data can be transmitted therebetween using a suitable connection arrangement (e.g., an internal bus as known in the art) including an inter-IC (I2C) bus, wiring, and printed circuit boards. For example, in system A, processing module 80 is interconnected to the other elements of the system A via bus 805.

[0147] The communication interface 804 of the processing module 80 allows the system A to communicate over the communication network 81. The communication network 81 may be implemented, for example, within a wired and / or wireless medium.

[0148] In various embodiments, data is streamed or otherwise provided to system A using a wireless network, such as a Wi-Fi network, e.g., IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers). Wi-Fi signals of these embodiments are received on a communication network 81 and a communication interface 804 adapted for Wi-Fi communication. The communication network 81 of these embodiments is typically connected to an access point or router that provides access to external networks, including the Internet for allowing streaming applications and other over-the-top communications. Still other embodiments provide streaming data to system A using the RF connection of input block 60. As indicated above, various embodiments provide data in a non-streaming manner, e.g., when system A is a smartphone or tablet. In addition, various embodiments use wireless networks other than Wi-Fi, e.g., a cellular network or a Bluetooth network.

[0149] System A can provide output signals to various output devices using the communication network 81 or bus 805. For example, system A can provide decoded SDR or HDR signals.

[0150] System A can provide output signals to various output devices, including display 64 (if, e.g., system A is a set-top box providing decoded SDR or HDR signals to a display device), speakers 65, and other peripheral devices 66. Display 64 of various embodiments includes one or more of, e.g., a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. Display 64 can be for a television, a tablet, a laptop, a cellular phone (mobile phone), or other device. Display 64 can also be integrated with other components (e.g., as in a smartphone) or separate (e.g., an external monitor for a laptop). Display device 64 is SDR or HDR content compatible. In various examples of embodiments, other peripheral devices 66 include one or more of a stand-alone digital video disc (or digital versatile disc) (DVR, standing for both terms), a disc player, a stereo system, and / or a lighting system. Various embodiments use one or more peripheral devices 66 that provide functionality based on the output of system A. For example, a disc player performs the functionality of playing the output of system A.

[0151] In various embodiments, control signals are communicated between system A and display 64, speakers 65, or other peripheral devices 66 using signaling such as AV.Link, Consumer Electronics Control (CEC), or other communications protocols that enable device-to-device control with or without user intervention. Output devices can be communicatively coupled to system A through respective interfaces 61, 62, and 63 via dedicated connections. Alternatively, output devices can be connected to system A using communication network 81 via communication interface 804. Display 64 and speakers 65 can be integrated in a single unit with other components of system A in an electronic device such as, for example, a television. In various embodiments, display interface 61 includes a display driver such as, for example, a timing controller (TCon) chip.

[0152] Display 64 and speakers 65 can alternatively be separate from one or more of the other components, for example if the RF module of input 60 is part of a separate set-top box. In various embodiments in which display 64 and speakers 65 are external components, output signals can be provided via dedicated output connections including, for example, HDMI ports, USB ports, or COMP outputs.

[0153] Figure 8B A block diagram illustrating an example of a system B in which various aspects and embodiments can be implemented is shown in FIG. 8. System B is adapted to implement live production system 20, or a module or device of live production system 20, or master central control system 21, or a module or device of master central control system 21.

[0154] System B can be embodied as a device including various components and modules described above and configured to perform one or more of the aspects and embodiments described in the present document.

[0155] Examples of such devices include, but are not limited to, various electronic devices such as personal computers, laptop computers, cameras, smartphones, and servers. Individually or in combination, the elements or modules of system B can be embodied in a single integrated circuit (IC), multiple ICs, and / or discrete components. For example, in at least one embodiment, system B includes one processing module 80 that implements ITM tools (202A, 202B, 202C, 211) or TM tools (204A, 204B). In various embodiments, system B is communicatively coupled to one or more other systems or other electronic devices via, for example, a communications bus or through dedicated input and / or output ports.

[0156] Input to processing module 80 can be provided through various input modules as indicated in block 60, which has been described above. Figure 8C

[0157] ​The various elements of system B can be provided within an integrated housing. Within the integrated housing, the various elements can be interconnected and transmit data therebetween using suitable connection arrangements including an Inter-IC (I2C) bus, wiring, and printed circuit boards (e.g., internal buses as known in the art). For example, in system B, processing module 80 is interconnected to other elements of the system B by bus 805.

[0158] Communication interface 804 of processing module 80 allows system B to communicate over communication network 81. Communication network 81 can be implemented, for example, within wired and / or wireless media.

[0159] In various embodiments, data is streamed or otherwise provided to system B using a wireless network, such as a Wi-Fi network, e.g., IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers). Wi-Fi signals of these embodiments are received over communication network 81 and communication interface 804 that are adapted for Wi-Fi communication. Communication network 81 of these embodiments is typically connected to an access point or router that provides access to external networks, including the Internet, for allowing streaming applications and other over-the-top communications. Still other embodiments provide streaming data to system B using the RF connection of input block 60. As indicated above, various embodiments provide data in a non-streaming manner.

[0160] When a diagram is presented as a flow chart, it will also be appreciated that it provides a block diagram of corresponding means. Similarly, when a diagram is presented as a block diagram, it will also be appreciated that it provides a flow chart of corresponding methods / processes.

[0161] Implementations and aspects described herein can be implemented in, for example, a method or process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single form of implementation, a feature can be implemented in other forms (e.g., an apparatus or program). An apparatus can be implemented in, for example, appropriate hardware, software, and firmware. The methods can be implemented in, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, such as, for example, computers, cell phones, portable / personal digital assistants (“PDAs”), smart phones, tablets, and other devices that facilitate communication of information between end-users.

[0162] Reference to "one embodiment" or "an embodiment" or "one implementation" or "an implementation", as well as other variants, means that a particular feature, structure, characteristic, and so forth being described in connection with the embodiment is included in at least one embodiment. Therefore, the appearance of the phrase "in one embodiment" or "in an embodiment" or "in one implementation" or "in an implementation", as well any other variations, appearing in various places throughout this application are not necessarily all referring to the same embodiment.

[0163] Additionally, the application can refer to "determining" various pieces of information. Determining information can include one or more of, for example, estimating information, calculating information, predicting information, retrieving information from memory, or obtaining information from another device, module, or from a user.

[0164] Further, the application can refer to "accessing" various pieces of information. Accessing information can include one or more of, for example, receiving information, retrieving information (e.g., from memory), storing information, moving information, copying information, calculating information, determining information, predicting information, or estimating information.

[0165] Additionally, the application can refer to "receiving" various pieces of information. As with "accessing", receiving is intended to be a broad term. Receiving information can include one or more of, for example, accessing information or retrieving information (e.g., from memory). Further, "receiving" is typically involved, in one way or another, during operations such as, for example, storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0166] It will be appreciated that the use of any of the following " / ", "and / or", and "at least one of", for example, in the cases of "A / B" "A and / or B" and "at least one of A and B", is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B). As a further example, in the cases of "A, B, and / or C" and "at least one of A, B, and C", such phrasing is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and the second listed options (A and B) only, or the selection of the first and third listed options (A and C) only, or the selection of the second and third listed options (B and C) only, or the selection of all three options (A and B and C). This can be extended, as is clear to one of ordinary skill in this and related arts, for as many items as are listed.

[0167] As will be apparent to those of skill in the art, implementations or embodiments can produce a variety of signals formatted to carry information that can be, for example, stored or transmitted. The information can include, for example, instructions for performing a method, or data created by one of the described implementations or embodiments. For example, a signal can be formatted to carry an HDR or SDR image or video sequence and interoperability metadata of the described embodiments. Such a signal can be formatted, for example, as an electromagnetic wave (for example, using the radio frequency part of the spectrum), or baseband signal. The formatting can include, for example, encoding the HDR or SDR image or video sequence with interoperability metadata in an encoded stream and modulating a carrier with the encoded stream. The information that the signal carries can be, for example, analog or digital information. The signal can be transmitted over a variety of different wired or wireless links, as is known. The signal can be stored on a processor-readable medium.

[0168] We described above multiple embodiments. Features of these embodiments can be provided individually or in any combination. Further, embodiments can include one or more of the following features, devices or aspects, individually or in any combination, across various claim categories and types: • a bitstream or signal including one or more of the described SDR or HDR data and interoperability metadata or variations thereof. • creating and / or transmitting and / or receiving and / or decoding a bitstream or signal including one or more of the described SDR or HDR data and / or interoperability metadata or variations thereof. • a server, camera, TV, set-top box, cell phone, tablet, personal computer, or other electronic device that performs at least one of the described embodiments. • a TV, set-top box, cell phone, tablet, personal computer, or other electronic device that performs at least one of the described embodiments and displays (for example, using a monitor, screen, or other type of display) the resulting image. • a TV, set-top box, cell phone, tablet, personal computer, or other electronic device that tunes (for example, using a tuner) a channel to receive a signal including encoded SDR or HDR data and interoperability metadata and performs at least one of the described embodiments. • a TV, set-top box, cell phone, tablet, or other electronic device that over-the-air receives (for example, using an antenna) a signal including SDR or HDR data and interoperability metadata and performs at least one of the described embodiments. • a server, camera, cell phone, tablet, personal computer, or other electronic device that tunes (for example, using a tuner) a channel to transmit a signal including SDR or HDR data and interoperability metadata and performs at least one of the described embodiments. • A server, camera, cell phone, tablet, personal computer, or other electronic device that transmits signals including SDR or HDR data and interoperability metadata over the air (e.g., using an antenna) and performs at least one of the described embodiments.

Claims

1. A method comprising: obtaining (501) input video data within an input dynamic range; obtaining (502) interoperability metadata representing input video data within the input dynamic range and enabling conversion of the input video data into output video data within an output dynamic range; transmitting (503) the input video data and the interoperability metadata; The interoperability metadata includes at least one of information representing an HDR diffuse white value, information representing an SDR diffuse white value, information representing an HDR narrow range value, information representing an HDR narrow full range value, information representing an SDR narrow full range maximum value, and information representing a narrow full range minimum value.

2. The method of claim 1, wherein the input dynamic range is HDR or SDR.

3. The method of claim 1 or 2, wherein the interoperability metadata is transmitted using an auxiliary channel of an SDI interface.

4. The method of claim 3, wherein the interoperability metadata is embedded in SL-HDR1 metadata.

5. The method of any preceding claim as claimed in any preceding claim, wherein the interoperability metadata is transmitted using a SEI message.

6. A method comprising: Obtaining (601) input video data within an input dynamic range and interoperability metadata, the interoperability metadata representing the input video data within the input dynamic range and allowing conversion of the input video data into output video data within an output dynamic range; converting (602) the input video data into output video data within the output dynamic range using the interoperability metadata; The interoperability metadata includes at least one of information representing an HDR diffuse white value, information representing an SDR diffuse white value, information representing an HDR narrow range value, information representing an HDR narrow full range value, information representing an SDR narrow full range maximum value, and information representing a narrow full range minimum value. The method of claim 6 , wherein the input dynamic range is HDR or SDR.

8. A method as claimed in claim 6 or 7, wherein the interoperability metadata is used to define a tone mapping process, which allows the input video data to be converted from the input dynamic range to the output dynamic range in response to the input dynamic range being HDR and the output dynamic range being SDR, and the interoperability metadata is used to define an inverse tone mapping process, which allows the input video data to be converted from the input dynamic range to the output dynamic range in response to the input dynamic range being SDR and the output dynamic range being HDR.

9. The method of claim 6, 7 or 8, wherein the interoperability metadata is received using an auxiliary channel of an SDI interface.

10. The method of claim 9, wherein the interoperability metadata is embedded in SL-HDR1 metadata.

11. The method of any preceding claim as claimed in any preceding claim 6 to 9, wherein the interoperability metadata is transmitted using a SEI message.

12. A device comprising an electronic circuit configured to: obtaining (501) input video data within an input dynamic range; obtaining (502) interoperability metadata representing input video data within the input dynamic range and enabling conversion of the input video data within the input dynamic range into output video data within an output dynamic range; transmitting (503) the input video data and the interoperability metadata; The interoperability metadata includes at least one of information representing an HDR diffuse white value, information representing an SDR diffuse white value, information representing an HDR narrow range value, information representing an HDR narrow full range value, information representing an SDR narrow full range maximum value, and information representing a narrow full range minimum value.

13. The apparatus of claim 12, wherein the input dynamic range is HDR or SDR.

14. The apparatus of claim 12 or 13, wherein the interoperability metadata is transmitted using an auxiliary channel of an SDI interface.

15. The apparatus of claim 14, wherein the interoperability metadata is embedded in SL-HDR1 metadata.

16. The apparatus of any preceding claim 12 to 14, wherein the interoperability metadata is transmitted using a SEI message.

17. A device comprising an electronic circuit configured to: Obtaining (601) input video data within an input dynamic range and interoperability metadata, the interoperability metadata representing the input video data within the input dynamic range and allowing conversion of the input video data within the input dynamic range into output video data within an output dynamic range; converting (602) the input video data into output video data within the output dynamic range using the interoperability metadata; The interoperability metadata includes at least one of information representing an HDR diffuse white value, information representing an SDR diffuse white value, information representing an HDR narrow range value, information representing an HDR narrow full range value, information representing an SDR narrow full range maximum value, and information representing a narrow full range minimum value.

18. The apparatus of claim 17, wherein the input dynamic range is HDR or SDR.

19. An apparatus as claimed in claim 17 or 18, wherein the interoperability metadata is used to define a tone mapping process, which allows the input video data to be converted from the input dynamic range to the output dynamic range in response to the input dynamic range being HDR and the output dynamic range being SDR, and the interoperability metadata is used to define an inverse tone mapping process, which allows the input video data to be converted from the input dynamic range to the output dynamic range in response to the input dynamic range being SDR and the output dynamic range being HDR.

20. The apparatus of claim 17, 18 or 19, wherein the interoperability metadata is received using an auxiliary channel of an SDI interface.

21. The apparatus of claim 20, wherein the interoperability metadata is embedded in SL-HDR1 metadata.

22. The apparatus of any preceding claim 17 to 20, wherein the interoperability metadata is transmitted using a SEI message.

23. A non-transitory information storage medium storing program code instructions for implementing the method according to any preceding claim 1 to 11.

24. A signal comprising interoperability metadata representing input video data within an input dynamic range and enabling conversion of the input video data within the input dynamic range into output video data within an output dynamic range, comprising at least one of information representing an HDR diffuse white value, information representing an SDR diffuse white value, information representing an HDR narrow range value, information representing an HDR narrow full range value, information representing an SDR narrow full range maximum value, and information representing a narrow full range minimum value.

25. A computer program comprising program code instructions for implementing the method according to any preceding claim of claims 1 to 11.

Images