Guided conversion between two different dynamic ranges using new metadata

Abstract

A method comprising the steps of (601) obtaining input video data within an input dynamic range and interoperability metadata, and (602) converting the input video data into output video data within an output dynamic range using the interoperability metadata, wherein the interoperability metadata includes at least one of the following: information representing an HDR spread white value, information representing an SDR spread 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.

Description

Technical Field

[0001] At least one of the embodiments generally relates to the field of high dynamic range (HDR) video production, and more particularly, to methods, devices, and equipment that implement a signaling mechanism that enables identification of appropriate HDR-to-SDR or SDR-to-HDR conversion in a single master production and distribution system. This signaling mechanism enables interoperability between different devices and technologies in an actual workflow.

Background Art

[0002] Cross-reference to related applications This application claims priority to European Application No. 23305273.7, filed Mar. 2, 2023, which is hereby incorporated by reference in its entirety.

[0003] Recent advances in display technology have enabled an extended dynamic range of color, brightness, and contrast of the displayed image. The term image here refers to, for example, video, still images, or image content that can be an image.

[0004] High dynamic range video (HDR video) describes video having a greater dynamic range than that of standard dynamic range video (SDR video). HDR video involves capture, production, content / encoding, and display. In HDR capture and display devices, brighter whites and deeper blacks are possible. To accommodate this, HDR encoding standards enable a higher maximum brightness and use 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 is a transitional phase where both HDR and SDR content will coexist. During this coexistence phase, the same live content will be produced simultaneously in both HDR and SDR versions. Users can then choose to view either the HDR or SDR version of the content according to their preference or ability.

[0006] Current trends in the content creation industry are, firstly, the production of HDR content and then the automatic extraction of SDR content from HDR content using automated tools (known as a single-master production and distribution workflow), and secondly, the application of a controlled and secure approach to HDR production to avoid delivering substandard HDR or SDR content to users.

[0007] In this regard, several recommendations have been introduced by ITU-R documents (see, for example, Non-Patent Document 1 (hereinafter simply referred to as the BT.2408-3 report)). One important recommendation introduced in the BT.2408-3 report is the constraint of HDR diffuse white set to a fixed value equal to "203" nits. This constraint makes it possible to use a fixed 3D-LUT (lookup table) to implement 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 usages). By using these static LUTs, the system becomes static, i.e., the conversion (either ITM or TM) is fixed and does not adapt to the dynamic characteristics of the content. Dynamic conversion, based on the use of configurable and dynamic HDR diffuse white levels for both HDR to SDR (tone mapping) conversion and SDR to HDR (reverse tone mapping) conversion, provides a solution to address this problem.

[0008] Actual workflows are created using many different pieces of equipment from different providers. There is nothing preventing different providers from implementing different solutions on their equipment, such as different static 3D-LUTs or dynamic solutions. However, equipment implementing different solutions is generally not interoperable.

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

[0010] It is particularly desirable to propose a mechanism that ensures the selection of appropriate conversions and enables interoperability between different devices and technologies in actual workflows. [Prior art documents] [Non-patent literature]

[0011] [Non-Patent Document 1] “Report ITU-R BT.2408-3,Guidance for operational practices in HDR television production,07 / 2019” [Non-Patent Document 2] Recommendation ITU-R BT.709-6,Parameter values ​​for the HDTV standards for production and international program exchange,06 / 2015 [Non-Patent Document 3] Recommendation ITU-R BT.2100-2,Image parameter values ​​for high dynamic range television for use in production and international program exchange,07 / 2018 [Non-Patent Document 4] Recommendation EBU R103,Video signal tolerance in digital video systems version 3.0,05 / 2020 [Non-Patent Document 5] 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 [Non-Patent Document 6] 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 [Non-Patent Document 7] 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 / [Non-Patent Document 8] SMPTE ST 2108-1:2018,HDR / WCG Metadata Packing and Signaling in the Vertical Ancillary Data Space,10 / 2018 [Non-Patent Document 9] ETSI TS 103 433-1 v1.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 [Non-Patent Document 10] 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 [Overview of the Initiative]

[0012] In a first aspect, one or more of these embodiments provide a method comprising the steps of acquiring input video data within an input dynamic range, acquiring interoperability metadata, and transmitting the input video data and interoperability metadata, wherein the interoperability metadata includes at least one of the following: information representing an HDR spread white value, information representing an SDR spread 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.

[0013] In this embodiment, the input dynamic range is either HDR or SDR.

[0014] In this embodiment, interoperability metadata is transmitted using an auxiliary channel of the SDI interface.

[0015] In this embodiment, interoperability metadata is embedded in the SL-HDR1 metadata.

[0016] In this embodiment, interoperability metadata is transmitted using SEI messages.

[0017] In a second aspect, one or more of the present embodiments provide a method including steps of obtaining input video data within an input dynamic range and interoperability metadata, and converting the input video data into output video data within an output dynamic range using the interoperability metadata, where 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.

[0018] In an embodiment, the input dynamic range is HDR or SDR.

[0019] In an embodiment, the interoperability metadata is used to define a tone mapping process that enables conversion of input video data from an input to an 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 enables conversion of input video data from an input to an output dynamic range in response to the input dynamic range being SDR and the output dynamic range being HDR.

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

[0021] In an embodiment, the interoperability metadata is embedded in SL-HDR1 metadata.

[0022] In an embodiment, the interoperability metadata is transmitted using an SEI message.

[0023] In a third aspect, one or more of these embodiments provide a device comprising electronic circuits configured for acquiring input video data within an input dynamic range, acquiring interoperability metadata, and transmitting the input video data and interoperability metadata, wherein the interoperability metadata includes at least one of the following: information representing an HDR spread white value, information representing an SDR spread 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.

[0024] In this embodiment, the input dynamic range is either HDR or SDR.

[0025] In this embodiment, interoperability metadata is transmitted using an auxiliary channel of the SDI interface.

[0026] In this embodiment, interoperability metadata is embedded in the SL-HDR1 metadata.

[0027] In this embodiment, interoperability metadata is transmitted using SEI messages.

[0028] In a fourth aspect, one or more of these embodiments provide a device comprising electronic circuitry configured for acquiring input video data and interoperability metadata within an input dynamic range, and for using the interoperability metadata to convert the input video data into output video data within an output dynamic range, wherein the interoperability metadata includes at least one of the following: information representing an HDR spread white value, information representing an SDR spread 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.

[0029] In this embodiment, the input dynamic range is either HDR or SDR.

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

[0031] In this embodiment, interoperability metadata is received using an auxiliary channel of the SDI interface.

[0032] In this embodiment, interoperability metadata is embedded in the SL-HDR1 metadata.

[0033] In this embodiment, interoperability metadata is transmitted using SEI messages.

[0034] In a fifth aspect, one or more of these embodiments provide a non-temporary information storage medium for storing program code instructions for implementing the method according to the first or second aspect.

[0035] In a sixth aspect, one or more of these embodiments provide a signal including interoperability metadata that includes at least one of the following: information representing HDR diffuse white value, information representing SDR diffuse white value, information representing HDR narrow range value, information representing HDR narrow full range value, information representing SDR narrow full range maximum value, and information representing narrow full range minimum value.

[0036] In the seventh aspect, one or more of these embodiments provide a computer program including program code instructions for implementing the method according to the first or second aspect. [Brief explanation of the drawing]

[0037] [Figure 1A] This figure shows the luminance value scale at which diffuse white appears. [Figure 1B] This figure shows the separation of the luminance value scale when diffuse white is fixed at "203" nits. [Figure 1C] This diagram schematically illustrates the context of various embodiments. [Figure 2] This diagram shows a single-master HDR / SDR workflow. [Figure 3A] This figure shows an example of a luminance ITM curve that conforms to the characteristics provided by interoperability metadata. [Figure 3B] This figure shows an example of a luminance TM curve that conforms to the characteristics provided by interoperability metadata. [Figure 4] This figure shows a single-master HDR / SDR workflow according to an embodiment. [Figure 5] This figure shows an example of processing performed by a video source according to the embodiment. [Figure 6] This figure shows an exemplary process performed by a device responsible for converting video data from a first dynamic range to a second dynamic range according to the embodiment. [Figure 7] This diagram provides an example of the process for introducing interoperability metadata into SL-HDR1 metadata. [Figure 8A] This diagram schematically illustrates an example of a hardware architecture for a processing module that can implement various aspects and embodiments. [Figure 8B] This is a block diagram of an example of a first system in which various aspects and embodiments are implemented. [Figure 8C] This is a block diagram of an example of a second system in which various aspects and embodiments are implemented. [Modes for carrying out the invention]

[0038] Below, we introduce some concepts used in various embodiments.

[0039] Diffuse White: As mentioned above, the BT.2408-3 report proposed several recommendations, particularly constraints on diffuse white. In the BT.2408-3 report, diffuse white is defined as "white provided by a card that approximates a perfect reflector diffuser by minimizing specular highlights and spectral power absorptivity, not merely by being calorimetrically gray but spectrally gray." A "perfect reflector diffuser" is defined as "an ideal isotropic, nonfluorescent diffuser with spectral emissivity equal to 1 at each wavelength of interest."

[0040] In other words, diffuse white is the luminance level of the video signal that separates the following: ●Scenes with all details, corresponding to brightness levels below diffuse white. ●Specular reflections: Extremely bright pixels that correspond to brightness levels above the diffuse white level, are generally close to white, and have very little detail.

[0041] Figure 1A shows the luminance value scale at which diffuse white appears. As can be seen, diffuse white separates the entire set of possible luminance values ​​into two parts.

[0042] The concept of diffuse white is valid for both HDR and SDR signals.

[0043] The BT.2408-3 report specifies that HDR diffuse white is equal to "203" nits.

[0044] However, the "203" nit constraint is merely a recommendation, and many content producers do not agree with it. In fact, HDR diffuse white equivalent to "203" nits presents significant problems, such as: HDR content becomes constrained; that is, in the case of typical "1000" nit HDR content, only a small portion of the HDR luminance range [0-203 nits] is dedicated to scene detail, while the largest portion of the HDR luminance range [203-1000 nits] is reserved for specular reflections that do not provide detail.

[0045] Figure 1B shows the separation of luminance values ​​on a scale when diffuse white is fixed at "203" nits.

[0046] One of the reasons for this restriction is the need for controlled, "highly secure" live HDR content production. In addition, this restriction has the following advantages: ● The HDR diffuse white defined in "203" nits needs to be mapped to the SDR diffuse white generally defined between 90% SDR and 100% SDR (i.e., between 90 nits and 100 nits), making the implementation of HDR to SDR conversion (i.e., tone mapping™) simpler. Therefore, tone mapping can be implemented using a very basic static 3D-LUT. ●Implementing SDR to HDR conversion (i.e., inverse tone mapping (ITM)) is also simpler for the same reasons, and inverse tone mapping can also be implemented using a very basic static 3D-LUT.

[0047] However, such a ratio between the luminance values ​​assigned to scene detail induced by diffuse white in "203" nit and the luminance values ​​assigned to specular reflection makes the resulting HDR image extremely dull and unappealing.

[0048] Narrow range and narrow full range: As described in Recommendations ITU-R BT.709-6 (Non-Patent Document 2) and ITU-R BT.2100-2 (Non-Patent Document 3), typical video signals are transmitted using the YCbCr representation, also known as the YUV representation.

[0049] In this representation, the quantization level is defined from the lowest value to the highest value. For example, when using "10" bit quantization, the luminance value is defined between a minimum value of "64" (black) and a maximum value of "940" (white), and the chromaticity value is defined between a minimum value of "64" and a maximum value of "960". These permitted ranges are generally referred to as the legal range, narrow range, or normal range. In the latter case, we use the term narrow range (NR).

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

[0051] The EBU R103 recommendation (Non-Patent Literature 4) provides some explanation for why a certain degree of tolerance is required when generating YCbCr signals and recommends not exceeding the range [20-984].

[0052] However, some implementations do not adhere to the range [20-984] recommended by Recommendation EBU R103, but instead utilize some range that starts with a value in range [4-1019] or range [4-63] and ends with a value in range [941-1019].

[0053] The combination of ranges [4-63] and [941-1019] (represented as [961-1019] respectively) and NR range [64-940] (represented as [64-960] respectively) is referred to as Narrow Full Range (NFR) in the latter case.

[0054] Range [4-63] is called Infrablack in the latter context.

[0055] The range [941-1019] (each [941-1019]) is called Super White in the latter case.

[0056] Typically, 3D-LUT implementations utilize these infrablack and superwhite ranges. For example, superwhite range is typically used to carry extra dynamic range that can be useful when performing SDR to HDR or HDR to SDR conversions.

[0057] Figure 1C shows an exemplary context in which various embodiments are implemented.

[0058] In Figure 1C, the live production system 20 communicates with the master central control system 21. The live production system 20 simultaneously provides both HDR and SDR versions of the same live content.

[0059] The master central control system 21 then encodes the same or enhanced versions of these SDR and HDR versions and provides these encoded versions to devices 22A and 22B. In the embodiment, the master central control system 21 encodes the HDR and SDR versions using an AVC (ISO / CEI 14496-10 / ITU-T H.264) encoder, a HEVC (ISO / IEC 23008-2-MPEG-H Part2, 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.

[0060] Devices 22A and 22B are connected to a display device such as a PC, TV, smartphone, tablet, or head-mounted display, or a set-top box. Device 22A, which has HDR capability, receives the encoded HDR version. Device 22B, which has only SDR capability, receives the encoded SDR version.

[0061] Figure 2 illustrates the single-master HDR / SDR workflow. Figure 2 provides details of the live production system 20 and the master central control system 21.

[0062] The live production system 20 has two sources: HDR source 200 and SDR source 201. Each source has at least one of the following: a camera, a playback system, or a graphics generating system. SDR source 201 is connected to several ITM tools as follows: ● One ITM tool 202A (ITM1) for upconverting SDR camera output to HDR. ● One ITM tool for upconverting SDR playback content to HDR: ITM 202B (ITM2), and ● One ITM tool 202C (ITM3) for upconverting SDR graphics (e.g., score insertion) content to HDR.

[0063] The HDR content routing and switching system 203 takes in multiple HDR inputs coming from either an HDR source 200 or an SDR source 201, and then generates multiple HDR outputs.

[0064] From these HDR outputs, the following TM tools are used: ●TM tool 204B (TM1) for generating a predicted SDR output used by a shader operator to evaluate the quality of the generated SDR content sent to the master central control system 21. ●TM tool 204A (TM2) for generating SDR provided to the master central control system 21

[0065] The master central control system 21 comprises an HDR master control system 212 and an SDR master control system 213. The HDR and SDR master control systems are responsible for distributing SDR / HDR content. In the example in Figure 2, the master central control system 21 comprises a source 210 that generates advertisements in SDR and an ITM tool 211 that converts the advertisements from SDR to HDR. The HDR master control system 212 receives these advertisements converted to HDR and mixes them with the HDR content it receives. The HDR (and SDR, respectively) master control systems 212 (and 213, respectively) encode the HDR (and SDR, respectively) that it receives, or the HDR (and SDR, respectively) resulting from a mixture of the HDR (and SDR, respectively) data it receives with other data. For example, the SDR and HDR data are encoded by an AVC encoder, HEVC encoder, VVC encoder, or any other encoder.

[0066] As can be seen in Figure 2, HDR content can originate from native HDR source 200. Because HDR content needs to be converted to SDR, currently TM tool 204B (TM1) and / or TM tool 204A (TM2) have no way of knowing the characteristics of the native HDR source, such as the HDR diffuse white value, NFR value, and which SDR diffuse white the HDR diffuse white maps to.

[0067] If the TM tool (204A or 204B) uses a specific static 3D-LUT, the only current solution is to ensure that the HDR source 200 is correctly configured to produce a video signal compatible with this particular 3D-LUT. However, there is nothing preventing the HDR source provider from configuring the HDR source 200 in a different way that is no longer compatible with this particular 3D-LUT. Similarly, there is nothing preventing the TM tool configurator from selecting a different static 3D-LUT that is not compatible with the HDR source 200. In fact, different static 3D-LUT solutions are available on the market. The following static 3D-LUT solutions can be listed: ●BBC LUT (see, for example, Non-Patent Document 5): The current version 1.5 of the BBC LUT solution describes "20" different 3D-LUTs for different usage / configurations. ●NBCU LUT (see, for example, Non-Patent Document 6): The current version 1.13 of the NBCU LUT solution describes "five" different 3D-LUTs for different usage / configurations. ●Recently, during the FIFA World Cup in Qatar, HBS designed its own HDR-to-SDR 3D-LUT (see, for example, Non-Patent Document 7).

[0068] All of these static LUTs are different, that is, ● HDR diffuse white value and SDR diffuse white value are different. ●Due to the different usage of SDR maximum NFR and HDR maximum NFR values, the maximum specular HDR value will differ. ●The NFR usage for these LUTs differs. ●The mapping of HDR values ​​to the maximum SDR NR value is different. ● Tone mapping curves and inverse tone mapping curves are different. ● The source transfer function and target transfer function may be different (the HDR transfer function can be either HLG or PQ).

[0069] Table TAB1 shows the values ​​for SDR and HDR diffuse white, SDR maximum NR, HDR value from SDR maximum NR, SDR maximum NFR, and HDR value from SDR maximum NFR, as shown below.

[0070] [Table 1]

[0071] This diversity in static 3D LUTs creates a risk of misconfiguration.

[0072] When a tone mapping tool uses a dynamic solution, it can adapt to the content thanks to its dynamic nature. However, because tone mapping tools lack information such as HDR and SDR diffuse white values ​​and NFR usage, the conversion may not be optimal. Knowing this information should enable dynamic tone mapping tools to produce more optimal HDR to SDR conversions.

[0073] Another aspect of Figure 2 is that the output of the HDR master control system 212 is a mixture of native SDR content and the main HDR video content. Such a situation commonly occurs in the case of live HDR content diffusion. For example, during the diffusion of content representing a live video event, logos, scores, and advertisements are mixed with the main HDR video representing the live sports event. As in the example in Figure 2, the added content is SDR and therefore may need to be converted to HDR before being mixed with the main HDR video content. Since the resulting mixed HDR content may be converted to SDR, a new constraint arises: the SDR content resulting from the so-called SDR-HDR-SDR round-trip conversion of these added contents (i.e., ITM conversion and subsequent TM conversion (for SDR distribution)) must be identical to the original SDR content. The same SDR-HDR-SDR round-trip constraint exists when a content producer generates HDR content from original SDR content, but for some reason wants the generated SDR content to be identical to the original SDR content.

[0074] In contexts where the use of static LUTs and / or dynamic solutions is uncontrolled, there is a high risk of misconfiguration and therefore a failure to respect SDR-HDR-SDR round-trip constraints.

[0075] Therefore, we need to find a solution that enables interoperability between instruments in a single-master HDR / SDR workflow. These solutions should therefore allow us to respect the SDR-HDR-SDR round-trip constraint.

[0076] The following proposes various embodiments based on the use of additional metadata called interoperability metadata.

[0077] In this embodiment, the interoperability metadata includes the following six pieces of information: ●HDR Diffuse White Value HDR_DW: HDR_DW gives the HDR diffuse white value of HDR content. HDR pixels with a luminance greater than HDR_DW are considered specular in HDR content. In the case of a potential subsequent SDR to HDR conversion, it indicates which HDR diffuse white value (as defined below) should be mapped to. It can be expressed in nits or in any coding representation relating to the nit value. ●SDR Diffuse White Value SDR_DW: SDR_DW provides the SDR diffuse white value for the desired subsequent HDR to SDR (TM) conversion. SDR pixels with luminance greater than SDR_DW are considered specular in the resulting SDR content from the TM conversion. It indicates which SDR diffuse white value HDR_DW should be mapped to. It can be expressed in nits or in any coding representation relating to the nit value. If the HDR content is native HDR content from an HDR source and SDR_DW is not present in the metadata, the TM tool is free to select an SDR diffuse white value. If the HDR content originates from an SDR source converted to HDR, SDR_DW can represent one of the following: ○ The SDR spread white value of the SDR content mapped to the HDR spread white value HDR_DW during ITM conversion. This allows the subsequent TM conversion to map the HDR spread white value to the SDR spread white value SDR_DW. This information therefore makes it possible to satisfy the SDR-HDR-SDR round-trip constraint. ○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 may differ from the source SDR diffuse white value, for example, in an 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 is an HDR luminance value that needs to be mapped to the narrow range maximum luminance value of the SDR content (i.e., "940" in the "10" bit codeword) during subsequent TM conversion. ●HDR Narrow Full Range Value HDR_NFR: HDR_NFR gives the HDR maximum brightness value that needs to be mapped to the narrow full range maximum brightness value SDR_NFR_MAX of the SDR content during subsequent TM conversion. ● SDR Narrow Full Range Maximum Value SDR_NFR_MAX: SDR_NFR_MAX gives the maximum luminance allowable value used in the upper part of the SDR narrow full range, corresponding to the HDR_NFR value of the corresponding HDR content. This value can be expressed as an "8" bit, "10" bit, or "12" bit value, or as a percentage of the narrow range. For example, this value is equal to "1019" in 10 bits (or 109% as a percentage of the narrow range) in the SDI / total video signal range, and "984" in a "10" bit codeword (or 105% as a percentage of the narrow range) according to the EBU R103 recommendation. SDR_NFR_MAX cannot be lower than the maximum narrow range value, i.e., "940" (or 100%) in 10 bit code. ● Narrow Full Range Minimum Value NFR_MIN: NFR_MIN gives the minimum allowable value used in the lower part of the narrow full range. This value can be expressed as an 8-bit, 10-bit, or 12-bit value, or as a percentage of the narrow range. For example, this value is equal to "4" in a 10-bit codeword (or -6.84% as a percentage of the narrow range) in the SDI / total video signal range, and according to the EBU R103 recommendation, it is "20" in a 10-bit codeword (or -5% as a percentage of the narrow range). This value cannot be higher than the minimum narrow range value, i.e., "64" in 10 bits (or 0%).

[0078] Interoperability metadata (and in particular these "six" pieces of information) allows for defining the characteristics that must be respected by TM and ITM curves used by TM and ITM tools in single-master HDR / SDR workflows (implemented, for example, in the form of 3D-LUTs in any static transformation or in any dynamic solution).

[0079] Figure 3A shows an example of a luminance ITM curve that conforms to the characteristics provided by interoperability metadata.

[0080] In the example shown in Figure 3A, the following applies: ● The NFR_MIN value of the input SDR content (e.g., equal to "4" in a "10" bit codeword) is mapped to the same NFR_MIN value of the output HDR content (i.e., "4" in a "10" bit codeword in this example). ● The narrow range minimum value of the input SDR content (64 in a 10-bit codeword) is mapped to the same narrow range minimum value of the output HDR content (64 in a 10-bit codeword). ● 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 value of the input SDR content (940 in a "10" bit codeword) is mapped to the HDR_NR value of the output HDR content. The SDR_NFR_MAX value of the input SDR content (e.g., equivalent to "1019" in a "10" bit codeword) is mapped to the HDR_NFR value of the output HDR content.

[0081] Figure 3B shows an example of a luminance TM curve that conforms to the characteristics provided by interoperability metadata.

[0082] In the example shown in Figure 3B, the following applies: ● The NFR_MIN value of the input HDR content (e.g., equal to "4" in a "10" bit codeword) is mapped to the same NFR_MIN value of the output SDR content (i.e., "4" in a "10" bit codeword in this example). ● The narrow range minimum value of the input HDR content (64 in a 10-bit codeword) is mapped to the same narrow range minimum value of the output SDR content (64 in a 10-bit codeword). ● 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 maximum narrow-range value of the output SDR content ("940" in a "10" bit codeword). ● The HDR_NFR value of the input HDR is mapped to the SDR_NFR_MAX value of the output SDR content (e.g., equivalent to "1019" for a "10" bit codeword).

[0083] Any static 3D-LUT can be characterized using interoperability metadata. As an example, in Table TAB2, we mapped the "six" pieces of information provided by the interoperability metadata to the values ​​of SDR and HDR diffuse white, SDR maximum NR, HDR value from SDR maximum NR, SDR maximum NFR, and HDR value from SDR maximum NFR that characterize an existing 3D-LUT represented in Table TAB1.

[0084] [Table 2]

[0085] More generally, any static converter can be characterized using interoperability metadata. Similarly, any dynamic converter capable of managing this interoperability metadata can produce dynamic transformation curves that are compatible with the interoperability metadata.

[0086] Figure 4 shows the single-master HDR / SDR workflow from Figure 2 where interoperability metadata (IMD) is used.

[0087] As can be seen in Figure 4, each device that generates HDR data transmits interoperability metadata along with the HDR data. The devices that generate HDR data include HDR source 200, ITM tools 202A, 202B, and 202C, and 211.

[0088] In the embodiment, interoperability metadata is provided to TM tools 204A and 204B to guide the TM processing applied to HDR data in order to generate SDR data.

[0089] In this embodiment, interoperability metadata is delivered along with the HDR data by the HDR master control system 212. In this embodiment, the interoperability metadata is used to guide the TM processing applied to the delivered HDR data.

[0090] In some embodiments, interoperability metadata can also be associated with SDR data. In this case, the interoperability metadata is generated by the equipment that generates the SDR data. The equipment that generates the SDR data is, for example, SDR source 201, TM tools 204A and 204B. In the example in Figure 4, when associated with SDR data, the interoperability metadata can be delivered together with the SDR data by the SDR master control system 213. In this case, the interoperability metadata is used to guide the ITM processing applied to the delivered SDR data.

[0091] As can be seen from the example in Table TAB2, interoperability metadata can be used to characterize either TM processing or ITM processing.

[0092] When transmitted with HDR data, interoperability metadata characterizing the TM process allows, for example, a TM tool to directly identify which TM process (i.e., which TM curve or 3D LUT defining the TM curve) is applied.

[0093] When transmitted with HDR data, interoperability metadata characterizing the ITM processing allows, for example, a TM tool to identify the characteristics of the HDR data or which ITM processing (i.e., which ITM curve or 3D LUT defining the ITM curve) was applied to acquire the HDR data. In this case, from the interoperability metadata, the TM tool can determine a TM processing that is compatible with the characteristics of the HDR data or the ITM processing applied to acquire the HDR data. In some embodiments, the determined TM processing can ensure SDR-HDR-SDR round-trip constraints.

[0094] When transmitted with SDR data, interoperability metadata characterizing ITM processing allows, for example, an ITM tool to directly identify which ITM processing (i.e., which ITM curve or 3D LUT defining the ITM curve) is applied.

[0095] When transmitted with SDR data, interoperability metadata characterizing the TM processing allows, for example, an ITM tool to identify the characteristics of the SDR data or which TM processing (i.e., which TM curve or 3D LUT defining the TM curve) was applied to acquire the SDR data. In this case, from the interoperability metadata, the ITM tool can determine an ITM processing that is compatible with the characteristics of the SDR data or the TM processing applied to acquire the SDR data. In this case as well, the determined TM processing can ensure the SDR-HDR-SDR round-trip constraint.

[0096] Figure 5 shows an example of processing performed by a video source according to the embodiment.

[0097] The processing shown in Figure 5 is performed by the video source processing module. The video sources are, for example, HDR source 200, SDR source 201, ITM tools 202A, 202B, 202C or 211, or TM tool 204A or 204B.

[0098] In step 501, the processing module acquires input video data within the input dynamic range. The input dynamic range can be HDR or SDR.

[0099] In step 502, the processing module obtains interoperability metadata. The interoperability metadata may characterize either the input video data within 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 the 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.

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

[0101] Figure 6 shows an exemplary process performed by a device responsible for converting video data from a first dynamic range to a second dynamic range according to the embodiment.

[0102] The processing shown in Figure 6 is performed by a processing module of a device responsible for converting video data from a first dynamic range to a second dynamic range. The device is, for example, the TM Tool 204A or 204B.

[0103] In step 601, the processing module acquires input video data and interoperability metadata within the input dynamic range. In this case, the input dynamic range can be HDR or SDR. In one example, the input video data and interoperability metadata are received by TM tool 204A or 204B from HDR source 200 or from ITM tool 202A, 202B, or 202C. In another example, the input video data is received by the instrument from HDR source 200 or from ITM tool 202A, 202B, or 202C via HDR control system 212 or SDR master control system 213.

[0104] In step 602, the processing module uses interoperability metadata to convert the input video data into output video data within a second dynamic range. 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.

[0105] The adapted solution is required to transport HDR or SDR data along with interoperability metadata between modules of a production system (for example, between HDR sources 200 in a live production system 20 or from ITM tools 202A, 202B, or 202C and TM tools 204A and 204B) or to distribute HDR or SDR data and interoperability metadata to external devices after production (for example, via a master central control system 21). A typical production system (such as a live production system 20) uses SDI (Serial Digital Interface) interconnects that conform to the SMPTE standard suite to exchange data within the system. Auxiliary channels of the SDI interface allow for the exchange of additional information, such as metadata. For example, metadata can be exchanged using a vertical auxiliary channel (hereinafter referred to as SDI VANC), as described in standard SMPTE ST2108-1 (see, for example, Non-Patent Literature 8). Interoperability metadata can also be exchanged using the same SDI-based mechanism.

[0106] The first solution for transporting HDR or SDR data along with interoperability metadata is based on SL-HDR1. SL-HDR1 (Non-Patent Literature 9) is a standard that enables the representation of HDR content by an SDR signal along with dynamic metadata. The SDR signal arises from tone mapping™ of HDR content, which applies a tone mapping tool based on a tone mapping curve. The dynamic metadata represents an inverse tone mapping curve that enables the inverse conversion of the SDR signal to an HDR signal.

[0107] 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 to transport interoperability metadata.

[0108] Figure 7 provides an example of the process for introducing interoperability metadata into SL-HDR1 metadata. This process is implemented by the processing module of the HDR source (e.g., HDR source 200) or by an ITM tool (e.g., ITM tools 202A, 202B, 202C, or 211). This process is performed, for example, in step 503.

[0109] 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 length in bytes of the SL-HDR extended data byte.

[0110] In step 702, the processing module signals the value of the SDR diffuse white SDR_DW in nitrate form with two bytes, sl_hdr_extension_data_byte[0] and sl_hdr_extension_data_byte[1], where sl_hdr_extension_data_byte[0] is the least significant byte of the 16-bit integer value and sl_hdr_extension_data_byte[1] is the most significant byte.

[0111] In step 703, the processing module signals the value of HDR Diffuse White HDR_DW in nitrile form with two bytes, SL-HDR extension databytes sl_hdr_extension_data_byte[2] and sl_hdr_extension_data_byte[3], where sl_hdr_extension_data_byte[2] is the least significant byte of a "16" bit integer value and sl_hdr_extension_data_byte[3] is the most significant byte.

[0112] In step 704, the processing module signals the HDR narrow range value HDR_NR (in nitriles) with two bytes, sl_hdr_extension_data_byte[4] and sl_hdr_extension_data_byte[5], where sl_hdr_extension_data_byte[4] is the least significant byte of a "16" bit integer value and sl_hdr_extension_data_byte[5] is the most significant byte.

[0113] In step 705, the processing module signals the HDR narrow full range value (in nitriles) HDR_NFR with two bytes, sl_hdr_extension_data_byte[6] and sl_hdr_extension_data_byte[7], where sl_hdr_extension_data_byte[6] is the least significant byte of a "16" bit integer value and sl_hdr_extension_data_byte[7] is the most significant byte.

[0114] In step 706, the processing module signals the narrow full-range minimum value NFR_MIN with two bytes, sl_hdr_extension_data_byte[8] and sl_hdr_extension_data_byte[9], where sl_hdr_extension_data_byte[8] is the least significant byte of a "16" bit integer value and sl_hdr_extension_data_byte[9] is the most significant byte. The signaled value of NFR_MIN can be conventionally defined to represent, for example, a "10" bit value. For systems managing signals with different bit depths, such as 8-bit or 12-bit content, this 10-bit codeword can therefore be easily converted to an 8-bit codeword, a 12-bit codeword, and so on.

[0115] In step 707, the processing module signals the SDR narrow full-range maximum value SDR_NFR_MAX with two bytes, sl_hdr_extension_data_byte

[10] and sl_hdr_extension_data_byte

[11] , where sl_hdr_extension_data_byte

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

[11] is the most significant byte. The signaled value of SDR_NFR_MAX can be conventionally defined to represent, for example, a 10-bit value. For systems managing signals with different bit depths, such as 8-bit or 12-bit content, this 10-bit codeword can therefore be converted to an 8-bit codeword, a 12-bit codeword, and so on.

[0116] If any metadata already exists in the SL-HDR extended databytes, the six new metadata entries can also be added before or after these existing metadata entries. Any other representation of the "six" pieces of information in the SL-HDR1 metadata is also possible, for example, with fewer or more bytes for each piece of information, or without byte alignment.

[0117] Another solution for transporting video data along with interoperability metadata involves transporting the metadata within SEI messages.

[0118] Video compression standards such as VVC, HEVC, and AVC define messages called Supplemental Enhancement Information (SEI) messages, which contain metadata that provides information related to the video stream. An SEI message is a data container or syntax structure associated with the video stream.

[0119] SEI messages provide a solution for transporting interoperability metadata. New SEI messages specifically for transporting interoperability metadata may be defined.

[0120] These SEI messages can be transported in the form of SDI VANC messages, as defined in SMPTE ST2108-1.

[0121] It should be noted that these SEI messages can, as an alternative, be inserted into the transport stream along with an encoded video stream delivered by the master central control system.

[0122] As already mentioned, many existing video devices have embedded HDR to SDR™ or SDR to HDR™ conversions. These conversions can be achieved either by using static 3D-LUTs or by using dynamic solutions.

[0123] In this context, several scenarios for using interoperability metadata are possible. Several different scenarios are provided below.

[0124] Scenario 1: Interoperability metadata matches a static 3D-LUT known by the module responsible for the transformation.

[0125] When the "six" pieces of information included in the interoperability metadata match a 3D-LUT known to the module responsible for the conversion, selecting the 3D-LUT to apply is straightforward for the conversion module.

[0126] For example, if a single-master HDR / SDR workflow uses HLG content and the "six" pieces of information are as follows: ●SDR_DW=86 ●HDR_DW=203 ●NFR_MIN=4 ●SDR_NFR_MAX=1006 ●HDR_NR=294 ●HDR_NFR=1810

[0127] In that case, NBCU LUT 3, as listed in Table TAB2, is the appropriate choice.

[0128] Second scenario: The interoperability metadata does not match any static 3D-LUTs known to the module responsible for the conversion.

[0129] When the "six" pieces of information in the interoperability metadata do not match a single static 3D-LUT known by the conversion module, the instrument determines which 3D-LUT is most likely to be appropriate. Many different algorithms can be defined for this purpose. For example, ●The decision is made based solely on the HDR_DW value, and a 3D-LUT corresponding to the HDR diffuse white value closest to this HDR_DW value is selected. ●The decision is made based solely on the HDR_DW value, and a 3D-LUT is selected that corresponds to an HDR diffuse white value that is closer to but lower than this HDR_DW value. ●The decision is made based solely on the HDR_DW value, and a 3D-LUT is selected that corresponds to an HDR diffuse white value that is closer to but higher than this HDR_DW value. ●The decision is made based solely on the SDR_DW value, and a 3D-LUT corresponding to the SDR diffuse white value closest to this SDR_DW value is selected. ●The decision is made based solely on the SDR_DW value, and a 3D-LUT is selected that corresponds to an SDR diffuse white value that is closer to but lower than this SDR_DW value. ●The decision is made based solely on the SDR_DW value, and a 3D-LUT is selected that corresponds to an SDR diffuse white value that is closer to but higher than this SDR_DW value. ●The decision is made based on both the HDR_DW value and the SDR_DW value, and the 3D-LUT corresponding to the HDR diffuse white value and SDR diffuse white value that are closest to these HDR_DW and SDR_DW values ​​is selected. ● Based on the HDR_DW and SDR_DW values, a 3D-LUT is selected that corresponds to HDR diffuse white values ​​and SDR diffuse white values ​​that are closer to but lower than these HDR_DW and SDR_DW values. ●The decision is made based solely on the HDR_DW and SDR_DW values, and a 3D-LUT is selected that corresponds to HDR diffuse white values ​​and SDR diffuse white values ​​that are closer to but higher than these HDR_DW and SDR_DW values. ● A decision is made based on any combination of information "1" through "6," and the 3D-LUT is selected that best matches the characteristics "1" through "6" that characterize the 3D-LUT.

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

[0131] Third scenario: Interoperability metadata is used to mimic existing single-master HDR / SDR workflows.

[0132] Some existing single-master HDR / SDR workflows (for example, the one proposed by the NBCU (see Non-Patent Document 10)) recommend the use of specific static 3D-LUTs for SDR-to-HDR and HDR-to-SDR conversions.

[0133] For example, when the NBCU workflow is used in Figure 2, ITM tools 202A, 202B, and 202C use ITM 3D-LUT NBCU LUT 1 (see Table TAB2), and TM tools 204A and 204B use Relative TM 3D-LUT NBCU LUT 3.

[0134] One way to ensure compatibility with the NBCU workflow is that when generating HDR content using ITM 3D-LUT NBCU LUT 1, the ITM tool fills the interoperability metadata with the corresponding SDR_DW, HDR_DW, NFR_MIN, SDR_NFR_MAX, HDR_NR, and HDR_NFR values ​​for the relative TM 3D-LUT NBCU LUT 3. Upon receiving the interoperability metadata, TM tools 204A and 204B select the 3D-LUT specified by the interoperability metadata, i.e., TM 3D-LUT NBCU LUT 3. The use of interoperability metadata makes the selection of the appropriate TM 3D-LUT automatic and reliable.

[0135] Fourth scenario: Interoperability metadata is used to improve SDR-HDR-SDR round trips in single-master HDR / SDR workflows.

[0136] In the previous scenario, SDR-HDR-SDR round trip is not guaranteed, but one objective of the fourth scenario is to show how SDR-HDR-SDR round trip can be improved using interoperability metadata. Taking the example of the single-master HDR / SDR workflow proposed by NBCU again, when generating HDR content using ITM 3D-LUT NBCU LUT 1, in the fourth scenario, the ITM tool fills the interoperability metadata with SDR_DW, HDR_DW, NFR_MIN, SDR_NFR_MAX, HDR_NR and HDR_NFR values ​​corresponding to ITM 3D-LUT NBCU LUT 1.

[0137] In that case, when the equipment (e.g., TM Tools 204A and 204B) receives HDR content along with interoperability metadata corresponding to ITM 3D-LUT NBCU LUT 1, it can select a newly defined TM 3D-LUT that perfectly matches the characteristics of ITM 3D-LUT NBCU LUT 1. Thus, this new TM 3D-LUT should enable a complete SDR-HDR-SDR round trip.

[0138] Scenario 5: Dynamic HDR to SDR Converter Configuration

[0139] Let's assume that the equipment (for example, TM Tools 204A and 204B) has embedded interoperability metadata and a compatible dynamic tone mapping solution, which means it can generate tone mapping curves like those shown in Figure 3B.

[0140] When a device receives native HDR content along with interoperability metadata, it uses "six" pieces of information to configure a dynamic solution, enabling the dynamic solution to provide appropriate TM conversion.

[0141] When a device receives HDR content resulting from an ITM conversion, along with interoperability metadata describing the characteristics of the ITM conversion, the device uses the "six" pieces of information to configure a dynamic system, enabling the dynamic system to provide an appropriate TM conversion, that is, it can respect the SDR-HDR-SDR round-trip constraint.

[0142] Whenever the interoperability metadata values ​​change from native HDR content or HDR content resulting from ITM conversion, dynamic solutions can always dynamically adapt to the new HDR content characteristics.

[0143] Figure 8A schematically shows examples of hardware architectures in the processing module 80 provided in the live production system 20, in the systems or modules provided in the live production system 20 such as ITM tools 202A, 202B, and 202C or TM tools 204B and 204A, in the master central control system 21, or in the systems or modules of the master central control system 21 such as ITM tool 211, or in devices 22A and 22B. The processing module 80 includes, in non-limiting examples, a processor or CPU (central processing unit) 800 connected by a communication bus 805, which includes one or more microprocessors, general-purpose computers, dedicated computers, and processors based on a multi-core architecture; a random access memory (RAM) 801; a read-only memory (ROM) 802; a storage unit 803 which may include non-volatile memory and / or volatile memory, including but not limited to storage media readers such as 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 memory, magnetic disk drives, and / or optical disk drives, or SD (Secure Digital) card readers and / or hard disk drives (HDDs) and / or network-accessible storage devices; and at least one communication interface 804 for exchanging data with other modules, devices, systems, or equipment. The communication interface 804 may include, but is not limited to, a transceiver configured to transmit and receive data over the communication network 81. The communication interface 804 may also include, but is not limited to, a modem or a network card.

[0144] For example, the communication interface 804 allows, for instance, the processing module 80 to process HDR or SDR data along with interoperability metadata.

[0145] The processor 80 can execute instructions loaded into RAM 801 from ROM 802, external memory (not shown), a storage medium, or a communication network. When the processing module 80 is powered on, the processor 800 can read instructions from RAM 801 and execute them. These instructions form computer programs that cause, for example, implementations by the processor 800 of HDR source 200, ITM tools 202A, 202B, 202C, and 211 in the method of Figure 5, and implementations by the processor 800 of TM tools 204A and 204B in the method of Figure 6.

[0146] All or part of the algorithms and steps of the above process may be implemented in software form by executing instruction sets by a programmable machine such as a DSP (Digital Signal Processor) or microcontroller, or in hardware form by a machine or dedicated component such as an FPGA (Field Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit).

[0147] Figure 8C shows a block diagram of an example of System A corresponding to device 22A or 22B, in which various aspects and embodiments are implemented.

[0148] System A can be comprised as a device comprising various components or modules and configured to generate SDR or HDR content adapted for display on an adapted display device. Examples of such systems include, but are not limited to, various electronic systems such as personal computers, laptop computers, smartphones, tablets, TVs, or set-top boxes. The components of System A can be comprised individually or in combination as a single integrated circuit (IC), multiple ICs, and / or individual components. For example, in at least one embodiment, System A comprises a processing module 80 that implements the decoding of SDR or HDR content. In various embodiments, System A is communicably coupled to one or more other systems or other electronic devices, for example, via a communication bus or through dedicated input and / or output ports.

[0149] Inputs to the processing module 80 can be provided through various input modules, as shown in block 60. Such input modules include, but are not limited to, (i) a radio frequency (RF) module for receiving 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. Other examples not shown in Figure 8C include composite video.

[0150] In various embodiments, the input module of block 60 has associated input processing elements as known in the Art. For example, an RF module can be associated with elements suitable for (i) selecting a desired frequency (also called 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 which (for example) in some embodiments may be called a channel, (iv) demodulating the down-converted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select a desired data packet stream. RF modules of various embodiments include one or more elements for performing these functions, for example, a frequency selector, a signal selector, a band-limiter, a channel selector, a filter, a downconverter, a demodulator, an error corrector, and a demultiplexer. The RF portion may include a tuner that performs various of these functions, for example, including down-converting a received signal to a lower frequency (e.g., an intermediate frequency or a quasi-baseband frequency) or to baseband. Various embodiments may rearrange the order of the elements described above (and others), remove some of these elements, and / or add other elements that perform similar or different functions. Adding elements may include inserting elements between existing elements, for example, inserting amplifiers and analog-to-digital converters. In various embodiments, the RF module includes an antenna.

[0151] Furthermore, the USB and / or HDMI modules may include their respective interface processors for connecting System A to other electronic devices via USB and / or HDMI connections. It should be understood that various aspects of input processing, such as Reed-Solomon error correction, can be implemented, for example, in a separate input processing IC or within the processing module 80 as needed. Similarly, aspects of USB or HDMI interface processing can be implemented in a separate interface IC or within the processing module 80 as needed. Demodulation, error correction, and demultiplexing of the stream are provided to the processing module 80.

[0152] Various elements of System A can be provided within an integrated housing. Within the integrated housing, the various elements are interconnected using internal buses known in the art, such as inter-IC (I2C) buses, wiring, and printed circuit boards, and data can be transmitted between them. For example, in System A, processing module 80 is interconnected to the other elements of System A by bus 805.

[0153] The communication interface 804 of the processing module 80 enables system A to communicate over the communication network 81. The communication network 81 can be implemented, for example, in a wired and / or wireless medium.

[0154] In various embodiments, the data is streamed to System A or otherwise provided using a wireless network such as a Wi-Fi network, for example, IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers). In these embodiments, the Wi-Fi signal is received via a communication network 81 and a communication interface 804 adapted for Wi-Fi communication. In these embodiments, the communication network 81 is typically connected to an access point or router that provides access to an external network, including the Internet, to enable streaming applications and other over-the-top communications. Yet another embodiment provides streaming data to System A using an RF connection of input block 60. As shown above, various embodiments provide data in a non-streaming manner, for example, when System A is a smartphone or tablet. Furthermore, various embodiments use wireless networks other than Wi-Fi, for example, a cellular network or a Bluetooth network.

[0155] 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.

[0156] System A can provide output signals to various output devices, including a display 64 (for example, if System A is a set-top box that provides decoded SDR or HDR signals to the display device), a speaker 65, and other peripheral devices 66. In various embodiments, the display 64 includes, for example, one or more of a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. The display 64 can be for a television, tablet, laptop, cell phone (mobile phone), or other device. The display 64 can also be integrated with other components (for example, as in a smartphone) or separate (for example, an external monitor for a laptop). The display device 64 is compatible with SDR or HDR content. Other peripheral devices 66, in various examples of embodiments, include one or more of a standalone digital video disc (or digital multi-purpose disc) (DVR in 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 function of playing the output of system A.

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

[0158] The display 64 and speaker 65 can, for example, be separate from one or more of the other components if the RF module of input 60 is part of a separate set-top box. In various embodiments where the display 64 and speaker 65 are external components, the output signals can be provided via dedicated output connections, such as an HDMI port, a USB port, or a COMP output.

[0159] Figure 8B shows a block diagram of an example of system B adapted to implement a live production system 20 or a module or device of the live production system 20, or a master central control system 21, or a module or device of the master central control system 21, which are implemented in various forms and embodiments.

[0160] System B can be comprised as a device including the various components and modules described above, and is configured to implement one or more of the embodiments and models described herein.

[0161] Examples of such devices include, but are not limited to, a variety of electronic devices such as personal computers, laptop computers, cameras, smartphones, and servers. Elements or modules of System B can be comprised, individually or in combination, of a single integrated circuit (IC), multiple ICs, and / or individual components. For example, in at least one embodiment, System B comprises a single processing module 80 implementing either an ITM tool (202A, 202B, 202C, 211) or a TM tool (204A, 204B). In various embodiments, System B is communicably coupled to one or more other systems or other electronic devices, for example, via a communication bus or through dedicated input and / or output ports.

[0162] Inputs to the processing module 80 can be provided through various input modules, such as those shown in block 60, which have already been described in relation to Figure 8C.

[0163] Various elements of System B can be provided within an integrated housing. Within the integrated housing, the various elements are interconnected using internal buses known in the art, such as inter-IC (I2C) buses, wiring, and printed circuit boards, and data can be transmitted between them. For example, in System B, processing module 80 is interconnected with other elements of System B by bus 805.

[0164] The communication interface 804 of the processing module 80 enables system B to communicate over the communication network 81. The communication network 81 can be implemented, for example, in a wired and / or wireless medium.

[0165] In various embodiments, the data is streamed to System B using a wireless network such as a Wi-Fi network, for example, IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers), or otherwise provided. In these embodiments, the Wi-Fi signal is received via a communication network 81 and a communication interface 804 adapted for Wi-Fi communication. In these embodiments, the communication network 81 is typically connected to an access point or router that provides access to an external network, including the Internet, to enable streaming applications and other over-the-top communications. Yet another embodiment provides streaming data to System B using an RF connection of input block 60. As shown above, various embodiments provide data in a non-streaming manner.

[0166] When a diagram is presented as a flow chart, it should be understood that it also provides a block diagram of the corresponding device. Similarly, when a diagram is presented as a block diagram, it should be understood that it also provides a flow chart of the corresponding method / process.

[0167] The implementations and embodiments described herein can be implemented, for example, in methods or processes, apparatus, software programs, data streams, or signals. Even when discussed only in the context of a single form of implementation (for example, discussed only as a method), the implementation of the function discussed can also be implemented in other forms (for example, apparatus or programs). Apparatus can be implemented, for example, in appropriate hardware, software, and firmware. Methods can be implemented, for example, in a processor, where processor refers to processing devices in general, including, for example, computers, microprocessors, integrated circuits, or programmable logic devices. Processors also include communication devices, such as, for example, computers, cell phones, portable / personal digital assistants ("PDAs"), smartphones, tablets, and other devices that facilitate the communication of information between end users.

[0168] The terms "one embodiment" or "embodiment" or "one implementation" or "implementation," as well as references to other variations thereof, mean that certain features, structures, characteristics, etc., described in relation to the embodiment are included in at least one embodiment. Therefore, the phrases "in one embodiment" or "in one embodiment" or "in one implementation" or "in implementation," appearing in various places throughout this application, as well as any other variations, do not necessarily all refer to the same embodiment.

[0169] Furthermore, this application may refer to "determining" various types of information. Determining information may include, for example, one or more of the following: estimating information, calculating information, predicting information, retrieving information from memory, or obtaining information from another device, module, or user, for example.

[0170] Furthermore, this application may refer to “accessing” various types of information. Accessing information may include, for example, receiving information, retrieving information (for example, from memory), storing information, moving information, copying information, computing information, determining information, predicting information, or estimating information.

[0171] Furthermore, this application may refer to "receiving" various types of information. Receiving is intended to be a broad term, as is "accessing." Receiving information may include, for example, accessing information or retrieving information (for example, from memory). Moreover, "receiving" is typically involved in some way 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.

[0172] Please understand that the use of any of the following is intended to include, for example, in the cases of "A / B", "A and / or B", "at least one of A and B", and "one or more of A and B", the selection of only the first listed option (A), or only the second listed option (B), or the selection of both options (A and B). As further examples, in the cases of "A, B, and / or C," "at least one of A, B, and C," and "one or more of A, B, and C," such phrasing is intended to encompass the selection of only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed options (A and C), or only the second and third listed options (B and C), or the selection of all three options (A, B, and C). This can be extended by as many as the number of items listed, as will be obvious to those skilled in the art in this and related fields.

[0173] As will be apparent to those skilled in the art, implementations or embodiments can produce a variety of signals formatted to carry information that can be stored or transmitted. This information may include, for example, instructions for carrying out a method, or data produced by one of the described implementations or embodiments. For example, a signal can be formatted to carry HDR or SDR images or video sequences and interoperability metadata of the described embodiments. Such a signal can be formatted, for example, as an electromagnetic wave (using, for example, the radio frequency portion of the spectrum) or as a baseband signal. The formatting may include, for example, encoding the HDR or SDR images or video sequences together with the interoperability metadata into an encoded stream, and modulating the carrier with the encoded stream. The information carried by the signal 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 in a processor-readable medium.

[0174] We have described numerous embodiments above. The functions of these embodiments can be provided individually or in any combination. Furthermore, embodiments may include, individually or in any combination, one or more of the following functions, devices, or aspects across various claim categories and types. ● A bitstream or signal containing one or more of the described SDR or HDR data and interoperability metadata, or variations thereof. ● To create and / or transmit and / or receive and / or decode a bitstream or signal containing 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 implements at least one of the embodiments described. A TV, set-top box, cell phone, tablet, personal computer, or other electronic device that implements at least one of the described embodiments and displays the resulting image (for example, using a monitor, screen, or other type of display). A TV, set-top box, cellphone, tablet, personal computer, or other electronic device that tunes a channel (for example, using a tuner) to receive a signal containing encoded SDR or HDR data and interoperability metadata, and implements at least one of the embodiments described. ● A TV, set-top box, cellphone, tablet, or other electronic device that receives a signal containing SDR or HDR data and interoperability metadata over the air (for example, using an antenna) and implements at least one of the embodiments described. A server, camera, cellphone, tablet, personal computer, or other electronic device that tunes a channel (for example, using a tuner) to transmit a signal containing SDR or HDR data and interoperability metadata, and implements at least one of the embodiments described. A server, camera, cellphone, tablet, personal computer, or other electronic device that transmits a signal containing SDR or HDR data and interoperability metadata over the air (for example, using an antenna) and implements at least one of the embodiments described.

Claims

1. Step (501) to acquire input video data within the input dynamic range, Step (502) of obtaining interoperability metadata that represents the input video data within the input dynamic range and enables conversion of the input video data to output video data within the output dynamic range, The steps include (503) transmitting the input video data and the interoperability metadata, A method including, The interoperability metadata includes at least one of the following pieces of information: information representing the HDR diffuse white value, information representing the SDR diffuse white value, information representing the HDR narrow range value, information representing the HDR narrow full range value, information representing the SDR narrow full range maximum value, and information representing the narrow full range minimum value.

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

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

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

5. The method according to any one of claims 1 to 3, wherein the interoperability metadata is transmitted using an SEI message.

6. Step (601) of obtaining input video data within the input dynamic range and interoperability metadata that represents the input video data within the input dynamic range and enables conversion of the input video data to output video data within the output dynamic range, Step (602) of converting the input video data into output video data within the output dynamic range using the interoperability metadata, A method including, The interoperability metadata includes at least one of the following pieces of information: information representing the HDR diffuse white value, information representing the SDR diffuse white value, information representing the HDR narrow range value, information representing the HDR narrow full range value, information representing the SDR narrow full range maximum value, and information representing the narrow full range minimum value.

7. The method according to claim 6, wherein the input dynamic range is HDR or SDR.

8. The interoperability metadata is used to define a tone mapping process that enables the 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 enables the 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. The method according to claim 6 or 7.

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

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

11. The method according to any one of claims 6 to 9, wherein the interoperability metadata is transmitted using an SEI message.

12. To acquire input video data within the input dynamic range (501), (502) Obtain interoperability metadata that represents the input video data within the input dynamic range and enables conversion of the input video data to output video data within the output dynamic range, and Transmitting the input video data and the interoperability metadata (503), A device comprising an electronic circuit configured for, The interoperability metadata includes at least one of the following: information representing the HDR diffuse white value, information representing the SDR diffuse white value, information representing the HDR narrow range value, information representing the HDR narrow full range value, information representing the SDR narrow full range maximum value, and information representing the narrow full range minimum value.

13. The device according to claim 12, wherein the input dynamic range is HDR or SDR.

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

15. The device according to claim 14, wherein the interoperability metadata is embedded in the SL-HDR1 metadata.

16. The interoperability metadata is transmitted using SEI messages, according to any one of claims 12 to 14.

17. (601) Obtaining input video data within the input dynamic range and interoperability metadata that represents the input video data within the input dynamic range and enables conversion of the input video data to output video data within the output dynamic range, and (602) Converting the input video data into output video data within the output dynamic range using the interoperability metadata, A device configured for, The interoperability metadata includes at least one of the following: information representing the HDR diffuse white value, information representing the SDR diffuse white value, information representing the HDR narrow range value, information representing the HDR narrow full range value, information representing the SDR narrow full range maximum value, and information representing the narrow full range minimum value.

18. The device according to claim 17, wherein the input dynamic range is HDR or SDR.

19. The interoperability metadata is used to define a tone mapping process that enables the 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 enables the 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. The device according to claim 17 or 18.

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

21. The device according to claim 20, wherein the interoperability metadata is embedded in the SL-HDR1 metadata.

22. The interoperability metadata is transmitted using SEI messages, according to any one of claims 17 to 20.

23. A non-temporary information storage medium for storing program code instructions for implementing the method according to any one of claims 1 to 11.

24. A signal comprising interoperability metadata that represents input video data within an input dynamic range and enables conversion of the input video data within the input dynamic range to output video data within an output dynamic range, the metadata comprising at least one of the following: information representing an HDR spread white value, information representing an SDR spread 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 one of claims 1 to 11.

Images