WO2015193114A1 - Procédé et dispositif pour signaler dans un train de bits un format d'image/de vidéo d'une image ldr et un format d'image/de vidéo d'une image hdr décodée obtenue depuis ladite image ldr image et une image d'éclairage - Google Patents

Procédé et dispositif pour signaler dans un train de bits un format d'image/de vidéo d'une image ldr et un format d'image/de vidéo d'une image hdr décodée obtenue depuis ladite image ldr image et une image d'éclairage Download PDF

Info

Publication number
WO2015193114A1
WO2015193114A1 PCT/EP2015/062473 EP2015062473W WO2015193114A1 WO 2015193114 A1 WO2015193114 A1 WO 2015193114A1 EP 2015062473 W EP2015062473 W EP 2015062473W WO 2015193114 A1 WO2015193114 A1 WO 2015193114A1
Authority
WO
WIPO (PCT)
Prior art keywords
picture
ldr
decoded version
syntax element
hdr
Prior art date
Application number
PCT/EP2015/062473
Other languages
English (en)
Inventor
Edouard Francois
Sebastien Lasserre
Fabrice Leleannec
Pierre Andrivon
Yannick Olivier
David Touze
Original Assignee
Thomson Licensing
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing filed Critical Thomson Licensing
Publication of WO2015193114A1 publication Critical patent/WO2015193114A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Definitions

  • the present disclosure generally relates to signaling output picture/video formats in a distribution framework comprising a dual modulation encoding/decoding scheme.
  • the present disclosure further relates to an encoding method which generates a bitstream representing a LDR picture and an illumination picture and a decoding method and device which decodes either a LDR or HDR picture according to an output picture/video format signaled by the bitstream.
  • a picture (sometimes called an image or frame in prior art) contains one or several arrays of samples (pixel values) in a specific picture/video format which specifies all information relative to the pixel values of a picture (or a video) and all information which may be used by a display and/or a decoding device to visualize and/or decode a picture (or video).
  • a picture comprises at least one component, in the shape of a first array of samples, usually a luma (or luminance) component, and, possibly, at least one other component, in the shape of at least one other array of samples, usually a color component.
  • LDR pictures Low-Dynamic-Range pictures
  • HDR pictures high-dynamic range pictures
  • luma samples are usually represented in floating-point format (either 32-bit or 16-bit for each component, namely float or half-float), the most popular format being openEXR half-float format (16-bit per RGB component, i.e. 48 bits per sample) or in integers with a long representation, typically at least 16 bits.
  • a dual modulation scheme is a typical approach for encoding an input HDR picture in a bitstream and for obtaining a decoded version of the input HDR picture by decoding the bitstream at least partially. Its principle is to obtain an illumination picture (also called illumination map or backlight picture) from the input HDR picture. A residual picture is then obtained by dividing the input HDR picture by the illumination picture and both the illumination picture (or illumination data representing the illumination picture) and the residual picture are then directly encoded.
  • an illumination picture also called illumination map or backlight picture
  • Encoding an input HDR picture using this approach leads to encode two components: a residual picture (called the LDR picture in the following), which may be a viewable picture, and illumination picture (or illumination data representing the illumination picture).
  • a decoded version of the LDR picture may then be obtained by directly decoding the bitstream at least partially, and a decoded version of the input HDR picture may also be obtained by multiplying the decoded version of the LDR picture by a decoded version of the illumination picture obtained by decoding the bitstream at least partially (or from illumination data obtained by decoding the bitstream at least partially).
  • the LDR and illumination pictures may have different input picture/video formats (YUV, RGB, XYZ, ...) and have not necessary the same format.
  • the illumination picture may be monochrome and the LDR picture format may be YUV or RGB.
  • the picture/video format of the decoded version of the input LDR picture may be the same as the formats of the input LDR and HDR pictures, respectively called the input LDR format and the input HDR format in the following.
  • the input formats and the output formats are usually not the same because it is advantageous that the output formats be adapted to specific conditions.
  • an output LDR or HDR format may be adapted to some targeted specific displays, ambient conditions for the display of the decoded pictures or user preferences.
  • Such adaptions of the output formats increase the visual quality of the decoded version of the pictures over said targeted specific displays because the encoding/decoding scheme optimizes the distribution of a given bit rate in order to reach the better visual quality for said targeted specific display.
  • the problem to be solved by the disclosure is that both a LDR or a
  • HDR picture which may be decoded from a same bitstream shall conform to a specific output LDR or HDR format which is different from the input LDR or HDR format.
  • the picture/video format of the input picture is signaled in the bistream using a syntax element: a so-called 'video usability information' (VUI) as defined, for example, in the HEVC recommendation ⁇ "High Efficiency Video Coding", SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS, Recommendation ITU-T H.265, Telecommunication Standardization Sector of ITU, April 2013) or H264/AVC recommendation ("Advanced video coding for generic audiovisual Services", SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS, Recommendation ITU-T H.264, Telecommunication Standardization Sector of ITU, February 2014)).
  • VUI 'video usability information'
  • the picture/video format of the decoded version of the input picture is then the picture/video format defined by the VUI, i.e. the same as the picture/format format of the input picture.
  • aspects of the present disclosure are directed to creating and maintaining semantic relationships between data objects on a computer system.
  • the following presents a simplified summary of the disclosure in order to provide a basic understanding of some aspects of the disclosure. This summary is not an extensive overview of the disclosure. It is not intended to identify key or critical elements of the disclosure. The following summary merely presents some aspects of the disclosure in a simplified form as a prelude to the more detailed description provided below.
  • the disclosure sets out to remedy some of the drawbacks of the prior art with a method for signaling, in a bitstream representing a LDR picture and an illumination picture both obtained from an HDR picture, both a picture/video format of a decoded version of said LDR picture, called an output LDR format, and a picture/video format of a decoded version of said HDR picture, called an output HDR format.
  • the method which comprises encoding in the bitstream a first syntax element defining the output LDR format, is characterized in that it further comprises encoding in the bitstream a second syntax element which is distinct from the first syntax element and which defines the output HDR format.
  • the disclosure further relates to an encoding/decoding method/device, a computer program product, a processor readable medium, a non-transitory storage medium and a signal.
  • FIG. 1 shows a block diagram of the steps of a method for encoding an HDR picture I in a bitstream F1 in which a LDR picture and an illumination picture are obtained from said HDR picture in accordance with an embodiment of the disclosure;
  • FIG. 2 shows a block diagram of a method for decoding a HDR picture or a LDR picture from a bitstream representing a LDR picture and an illumination picture in accordance with an embodiment of the disclosure
  • FIG. 3 shows an example of a VUI message representing an output
  • - Fig. 4 shows changes in the high level syntax of the HEVC specification to signal the presence of a new SEI message
  • - Fig. 5 shows an example of a SEI message representing an output
  • Fig. 5a shows a variant of the SEI message in Fig. 5.
  • FIG. 6 shows an example of an additional SEI message used to embed the data of the illumination picture
  • - Fig. 7 shows an example of a variant of the syntax of a SEI message representing the HDR output format shown in Fig. 5;
  • - Fig. 8 shows a block diagram of the substeps of the step 1 1 for encoding a LDR picture and an illumination picture both obtained from an HDR picture in accordance with an embodiment of the disclosure;
  • FIG. 9 shows a block diagram of the substeps of the step 21 for decoding a bitstream representing LDR and illumination pictures in accordance with an embodiment of the disclosure
  • Fig. 10 shows an example of the syntax of a SEI message relative to a frame-packing arrangement according to an embodiment of the disclosure
  • Fig. 11 shows a table given an interpretation of the flag
  • Fig. 12 shows a table given an interpretation of the flag "frame_packing_arrangement_type" of Fig. 10;
  • FIG. 13 shows an example of a frame-packing-arrangement scheme according to an embodiment of the disclosure
  • - Fig. 14 shows an example of a frame-packing-arrangement scheme according to an embodiment of the disclosure
  • FIG. 15 shows an example of a frame-packing-arrangement scheme according to a variant of an embodiment of the disclosure
  • FIG. 16 shows a block diagram of the substeps of the step 10 in accordance with an embodiment of the disclosure
  • FIG. 17 shows a block diagram of the substeps of the step 162 in accordance with an embodiment of the invention.
  • Fig. 18 shows a block diagram of the substeps of the step 162 in accordance with an embodiment of the invention
  • Fig. 19 shows a block diagram of the substeps of the step 162 in accordance with an embodiment of the invention.
  • FIG. 20 shows a block diagram of the steps of a method in accordance with a variant of the method as described in Fig. 1 ;
  • - Fig. 21 shows a block diagram of the steps of a method in accordance with a variant of the method as described in Fig. 2;
  • - Fig. 22-23 show an example of a SEI message representing an output LDR format and an example of a VUI message representing an output HDR format in accordance with an embodiment of the disclosure;
  • FIG. 24 shows an example of an architecture of a device in accordance with an embodiment of the disclosure.
  • - Fig. 25 shows two remote devices communicating over a communication network in accordance with an embodiment of the disclosure.
  • each block represents a circuit element, module, or portion of code which comprises one or more executable instructions for implementing the specified logical function(s).
  • the function(s) noted in the blocks may occur out of the order noted. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending on the functionality involved.
  • the methods described below are adapted to encode a HDR picture but may extend to encode a sequence of HDR pictures (video) because pictures of the sequence are encoded independently to each other.
  • the present disclosure relates to a method for signaling, in a bitstream, both a picture/video format of a decoded version of a LDR picture RF obtained from an HDR picture, called an output LDR format, and a picture/video format of a decoded version of said original HDR picture I, called an output HDR format.
  • the method comprises encoding in the bitstream a first syntax element defining the output LDR format and a second syntax element which is distinct from the first syntax element and which defines the output HDR format.
  • Fig. 1 shows a block diagram of the steps of a method for encoding an
  • HDR picture I in a bitstream F1 in which a LDR picture and an illumination picture are obtained from said HDR picture in accordance with an embodiment of the disclosure.
  • the method comprises a module FENC which is configured for encoding (step 12), in a bitstream F2, a first syntax element SE1 which defines the output LDR format, and a second syntax element SE2, which is distinct from the first syntax element SE1 , and which defines the output HDR format.
  • the illumination picture IF may comprise a triplet of illumination values for each sample of the input HDR picture I, each value of a triplet being an illumination value for a color component value of a sample.
  • the illumination picture IF may be either represented by a weighted linear combination of shape functions or a low-frequency version of the luminance component of the HDR picture I but the disclosure is not limited to any specific means for obtaining or representing an illumination picture IF relative to the HDR picture I to be encoded.
  • the LDR picture RF is usually a residual picture obtained from the HDR picture and the illumination picture IF.
  • the residual picture is obtained by dividing the HDR picture I by the illumination picture IF.
  • a splitter SPLM is configured for obtaining the LDR picture RF and the illumination picture IF.
  • the module SPLM is configured for obtaining either the LDR picture RF or the illumination picture IF or both from either a local/remote memory and/or from a communication network.
  • the module SPLM is configured for splitting the HDR picture I into the LDR picture RF and the illumination picture IF.
  • step 1 1 the LDR and illumination pictures (or, alternatively illumination data representing the illumination picture IF) are encoded by means of an encoder ENC.
  • the module FENC is further configured to encode some parameters Param used by the encoder ENC.
  • the parameters Param are encoded in the bitstream F2.
  • At least some parameters Param and the bitstream F1 are transmitted asynchronously.
  • Fig. 2 shows a block diagram of a method for decoding a HDR picture or a LDR picture from a bitstream representing the LDR picture and an illumination picture in accordance with an embodiment of the disclosure.
  • a module FDEC is configured for obtaining the first syntax element SE1 which defines the output LDR format and the second syntax element SE2 which defines the output HDR format by decoding the bitstream F2 at least partially.
  • the module FDEC is further configured for obtaining some parameters Param either from a local memory or by decoding the bitstream F2 at least partially.
  • At least some parameters Param and the bitstream F1 (and/or possibly F2) are received asynchronously.
  • a decoder DEC is configured for obtaining a decoded version RF of the LDR picture RF and a decoded version IF of the illumination picture IF by decoding the bitstream F1 at least partially.
  • the decoded version IF of the illumination picture IF may be obtained from illumination data.
  • the decoded version RF of the LDR picture RF and/or the decoded version IF of the illumination picture IF are obtained from a local memory.
  • the decoded version RF of the LDR picture RF is further obtained according to some parameters Param.
  • the decoded version RF of the LDR picture RF has a format which is defined by the output LDR format of first syntax element SE1 .
  • a module ISPLM is configured for obtaining a decoded version / of the HDR picture I from the decoded version RF of the LDR picture RF and the decoded version IF of the illumination picture IF.
  • the decoded version / of the HDR picture I has a format which is defined by the output HDR format of the second syntax element SE2.
  • the decoded version / of the HDR picture I is obtained according to some parameters Param.
  • the first syntax element SE1 is a VU l (Video Usability Information) message called, for example, "vui-parameterQ" and the second syntax element SE2 is a SEI message (Supplemental Enhancement Information) message called, for example dual-modulation-info() .
  • VU l Video Usability Information
  • SEI Supplemental Enhancement Information
  • Fig. 3 shows an example of the VUI message "vui-parameter()" representing an output LDR format whose the syntax complies with the HEVC recommendation in accordance with an embodiment of the disclosure.
  • the VUI message contains tags, which actually defines the output LDR format:
  • - video_format indicates the format of the LDR picture (e.g. PAL or SECAM);
  • - video_full_range_flag indicates if the LDR picture occupies the full available range of coded values or not
  • colour_description_present_flag is a flag equal to 1 that indicates if the three elements colour primaries, transfer characteristics and matrix_coeffs shall be used to enable a display to correctly render the colors.
  • - transfer_characteristics indicates the opto-electronic transfer characteristic of the LDR picture
  • - matrix_coeffs describes the matrix coefficients used in deriving luma and chroma components from the green, blue, and red primaries.
  • Fig. 5 show an example the SEI message dual-modulation-info() representing an output HDR format in accordance with an embodiment of the disclosure.
  • the SEI message dual-modulation-info() provides information about the output HDR format of the decoded version / of the HDR picture I.
  • - modulation_channel_cancel_flag 1 indicates that the SEI message dual-modulation-info() cancels the persistence of any previous SEI message dual-modulation-info() in output order.
  • modulation_channel_target_sample_format specifies the format of the samples of the luma and chroma sample arrays of the decoded version / of the HDR picture I.
  • the tag modulation_channel_target_sample_format equal to 0 indicates that the samples are in integer format. Values greater than 0 for modulation_channel_target_sample_format are reserved for future use by ITU-T I ISO/IEC. When not present, the value of modulation_channel_target_sample_format is inferred to be equal to 0.
  • the tag modulation_channel_target_sample_format equal to 1 to support the 16- bits half-float format.
  • the tag modulation_channel_target_sample_format equal to 2 to support the 32- bits full-float format.
  • modulation_channel_target_bit_chroma_format_idc has the same semantic as specified in subclause 7.4.3.2 of the above cited HEVC recommendation for the chroma_format_idc syntax element, except as follows: modulation_channel_target_bit_chroma_format_idc specifies the chroma format of the decoded version / of the HDR picture I, rather than the chroma format used for the Coded Video Sequence (CVS).
  • CVS Coded Video Sequence
  • modulation_channel_target_bit_chroma_format_idc When modulation_channel_target_bit_chroma_format_idc is not present in the SEI message dual-modulation-info() ⁇ the value of modulation_channel_target_bit_chroma_format_idc is inferred to be equal to chroma_format_idc (which relates to the LDR picture).
  • modulation_channel_target_bit_depth_luma_minus8 plus 8 specifies the bit depth of the samples of the luma sample array of decoded version / of the HDR picture I.
  • the tag modulation_channel_target_bit_depth_luma_minus8 shall be in the range 0 to 8 inclusive.
  • modulation_channel_target_bit_depth_luma_minus8 is not present in the SEI message "dual-modulation-info() ", the value of modulation_channel_target_bit_depth_luma_minus8 is inferred to be equal to bit_depth_luma_minus8.
  • modulation_channel_target_bit_depth_chroma_minus8 plus 8 specifies the bit depth of the samples of the chroma sample arrays of the decoded version / of the HDR picture I.
  • the tag modulation_channel_target_bit_depth_chroma_minus8 shall be in the range 0 to 8 inclusive.
  • modulation_channel_target_bit_depth_chroma_minus8 is not present in the SEI message "dual-modulation-info() ', the value of modulation_channel_target_bit_depth_chroma_minus8 is inferred to be equal to bit_depth_chroma_minus8.
  • modulation_channel_target_video_full_range_flag specifies the colour space used for the decoded version / of the HDR picture I, rather than the colour space used for the CVS.
  • modulation_channel_target_colour_primaries has the same semantics as specified in subclause E.2.1 of the above cited HEVC recommendation for the colour_primaries syntax element, except as follows: modulation_channel_target_colour_primaries specifies the colour space used for the decoded version / of the HDR picture I, rather than the colour space used for the CVS.
  • modulation_channel_target_colour_primaries is not present in the SEI message "dual-modulation-info() ", the value of modulation_channel_target_colour_primaries is inferred to be equal to colour primaries.
  • modulation_channel_target_transfer_characteristics has the same semantics as specified in subclause E.2.1 of the above cited HEVC recommendation for the transfer_characteristics syntax element, except as follows: modulation_channel_target_transfer_characteristics specifies the colour space used for the decoded version / of the HDR picture I, rather than the colour space used for the CVS.
  • modulation_channel_target_transfer_characteristics When modulation channel target transfer characteristics is not present in the SEI message dual-modulation-info() ⁇ the value of modulation_channel_target_transfer_characteristics is inferred to be equal to transfer characteristics.
  • modulation_channel_target_matrix_coeffs has the same semantics as specified in subclause E.2.1 of the above cited HEVC recommendation for the matrix_coeffs syntax element, except as follows: modulation_channel_target_matrix_coeffs specifies the colour space used for decoded version / of the HDR picture I, rather than the colour space used for the CVS.
  • modulation_channel_target_matrix_coeffs When modulation_channel_target_matrix_coeffs is not present in the SEI message "dual-modulation-info()", the value of modulation_channel_target_matrix_coeffs is inferred to be equal to matrix_coeffs.
  • the SEI message dual-modulation-info() further provides information to obtain the decoded version TP of the illumination picture IF used to obtain the decoded version / of the HDR picture I.
  • - modulation_channel_type indicates the mode used for generating the decoded version / of the HDR picture I.
  • the tag modulation_channel_type equal to 0 indicates that the decoded version TP of the illumination picture IF corresponds to the sample values of an auxiliary coded picture, possibly after upsampling if the auxiliary picture is of smaller width and/or height than a primary coded picture.
  • Note auxiliary and primary picture are defined by the above cited HEVC recommendation.
  • the tag modulation_channel_type indicates that the decoded version TP of the illumination picture IF is represented by a weighted linear combination of shape functions (PSF as explained below in details).
  • PSF shape functions
  • modulation_channel_type Values greater than 1 for modulation channel type are reserved for future use by ITU-T
  • the value of modulation_channel_type is inferred to be equal to 0.
  • the weighting coefficients which are applied to PSF to obtain the decoded version TP of the illumination picture IF are embedded in an auxiliary picture whose the syntax complies with the HEVC recommendation.
  • an additional SEI message "modulation_channel_info()" is specified in addition to the SEI message "dual_modulation_info()".
  • the weighting coefficients which are applied to PSF to obtain the decoded version TP of the illumination picture IF are embedded (coded) in the SEI message "modulation_channel_info()".
  • - modulation_channel_width corresponds to the number of samples per line of the weighting coefficient matrix of the first color component (which can for instance be the luma component, or the Y component).
  • - modulation_channel_height corresponds to the number of samples per column of the weighting coefficient matrix of the first color component (which can for instance be the luma component, or the Y component).
  • - modulation_channel_width_CbCr corresponds to the number of samples per line of the weighting coefficient matrix of the second and/or third color component (which can for instance be the chroma component, or the X or Z component).
  • - modulation_channel_height_CbCr corresponds to the number of samples per column of the weighting coefficient matrix of the second and/or third color component (which can for instance be the chroma component, or the X or Z component).
  • - modulation_channel_sample[ c ][cy ][cx] is the sample value of the sample of color component c at horizontal position cx and vertical position cy in the weighting coefficient matrices.
  • the SEI message dual-modulation-info() further provides information about parameters of post-processing intended to be apply to the decoded version of the LDR picture RF before multiplying it with the decoded version of the illumination picture IF.
  • modulation ldr mapping type relates to the type of process to be applied to the decoded version RF of the LDR picture RF. This tag indicates if the LDR picture is expressed in the Lab color space or in the YCbCr (or Yuv) color space.
  • look-up tables are embedded in the SEI message when the post-processing involve injective operations on individual sample values and when those successive operations can be concatenated into one single operation.
  • s s*RGB_factor/1024 where S, aO, bO, 0, RGB_factor are typically parameters embedded in the SEI message according to the previous variants.
  • modulation_channel_LUTO_size indicates the size of the array modulation channel LUT0 coefs - modulation_channel_LUTO_coefs corresponds to an array of size modulation_channel_LUTO_size, which applies to the samples of the first component array of the illumination picture.
  • - modulation_channel_LUT1_size indicates the size of the array modulation_channel_LUT1_coefs
  • modulation_channel_LUT1_coefs corresponds to an array of size modulation_channel_LUT1_size, which applies to the samples of the at least second component array of the illumination picture.
  • - modulation_LDR_LUTO_size indicates the size of the array modulation_LDR_LUTO_coefs
  • modulation_LDR_LUTO_coefs corresponds to an array of size modulation_LDR_LUTO_size, which applies to the samples of the first component array of the LDR picture.
  • - modulation_LDR_LUT1_size indicates the size of the array modulation_LDR_LUT1_coefs
  • modulation_LDR_LUT1_coefs corresponds to an array of size modulation_LDR_LUT1_size, which applies to the samples of the at least second component array of the LDR picture.
  • a variant of this alternative is to encode the parameters (for instance "modulation_slog_aO”, “modulation_slog_bO”, “modulation_slog_cO”, “modulation scaling factor”, “modulation RGB factor”) in the SEI message, prior to post-processing the sample values, to build the look-up tables from these parameters.
  • parameters for instance "modulation_slog_aO”, “modulation_slog_bO”, “modulation_slog_cO”, “modulation scaling factor”, “modulation RGB factor”
  • the weighting coefficient matrices may be encoded in the bitstream for each picture and the first and second syntax elements may remain unchanged.
  • the SEI message “dual-modulation-info()" can be simplified by enabling only the modulation mode corresponding to the signaling of a small array of weighting coefficients to be applied to localized PSFs for the reconstruction of the illumination picture. Indeed this variant enables reducing significantly the number of coded values (samples) in the SEI message, compared to the usual number of samples of the illumination picture (e.g. from several hundreds to a few thousand samples for an HD picture). This is therefore more adapted to the concept of SEI message that shall remain of reduced size. But the simplification can also apply for any type of signaling of the illumination picture, being frame packing or additional SEI message.
  • Fig. 7 shows an example of the simplified SEI message representing the HDR output format shown in Fig. 5.
  • the payload of any SEI message shall be indicated in a bitstream.
  • Fig. 4 shows an example of a SEI message signaling into a syntax structure called "SEI_payload". It is used for signaling in the bitstream F2 the specific SEI message described in relation with Fig. 5 (or Fig. 7).
  • the SEI payload "sei-payload()" has a syntax which complies with the HEVC recommendation except the text in bold which has been added to signal the SEI message dual-modulation-info() Note "XXX" is a fixed given value to be defined based on the already used values in the HEVC recommendation.
  • Fig. 8 shows a block diagram of the substeps of the step 1 1 for encoding the LDR picture and the illumination picture IF in accordance with an embodiment of the disclosure.
  • a second residual picture is obtained by subtracting a decoded version RF of the LDR picture RF from the HDR picture I.
  • This second residual picture is also called the second LDR picture in the following.
  • This second residual picture may be obtained by dividing the HDR picture I by the LDR picture RF.
  • the second residual picture then consists in ratio residual information between the HDR picture I and the LDR picture RF.
  • a module PACKM is configured to pack the LDR picture RF and the illumination picture IF (and possibly at least another picture such as the second residual picture) in a single frame SF according to a specific frame-packing-arrangement scheme FPAS.
  • an encoder VENC encodes the frame SF into the bitstream F1 .
  • the single frame SF is encoded according to encoding parameters which depend on the specific frame- packing-arrangement scheme. These parameters may be considered as being some parameters Param.
  • the encoding parameters are defined in order that the single frame be encoded in two distinct slices, one containing the LDR picture RF and the other slice containing the illumination picture IF.
  • These slices may also take the form of slice groups, tiles, tile groups, precincts, according to the standard encoding scheme employed (H.264/AVC, HEVC, JPEG2000).
  • This variant is advantageous because it allows that a specific processing, such a specific encoding, be applied on the illumination picture IF, respectively the LDR picture RF, and not on the LDR picture RF, respectively the illumination picture IF.
  • the bitstream F1 comprises thus the frame SF which contains samples of two distinct packed constituent pictures: the LDR picture RF and the illumination picture IF.
  • a module IDM processes an information data ID indicating that the frame SF contains samples of at least two distinct packed constituent pictures according to a specific frame-packing-arrangement scheme FPAS.
  • the information data ID comprises at least one flag and may be some parameters Param.
  • the module IDM is further configured to specify that the information data ID indicates that one of the at least two distinct packed constituent pictures corresponds to a LDR picture RF and another of the at least two distinct packed constituent pictures corresponds to an illumination picture IF associated with said LDR picture RF.
  • the information data ID further indicates that another of the at least two distinct packed constituent pictures corresponds to another picture such as for example the second residual picture, i.e. a residual picture obtained by subtracting an encoded/decoded version of the LDR picture from the LDR picture.
  • another picture such as for example the second residual picture, i.e. a residual picture obtained by subtracting an encoded/decoded version of the LDR picture from the LDR picture.
  • the information data ID identifies the specific frame-packing-arrangement scheme. Then, encoding parameters may be constrained by the specific frame-packing-arrangement scheme.
  • the module IDM is further configured to define that the information data ID indicates that the LDR and the illumination pictures do not have the same size (do not have the same numbers of rows or the same number of columns or both) and/or have specific positions in the frame SF.
  • the module IDM is further configured to define that the information data ID indicates the size (number of rows and number of columns) and/or a position of the LDR picture and/or the size and/or a position of the illumination picture.
  • the specific frame- packing-arrangement scheme indicates that either the LDR picture and/or the illumination picture is split in several pieces, and the module IDM is then configured to add, in the information data ID, at least one parameter to indicate the position of each piece in the frame SF.
  • the specific frame-packing-arrangement scheme FPAS and, possibly relative encoding parameters are some parameters Param.
  • the information data ID may be stored on a local or remote memory and/or transmitted through a communication interface (e.g. to a bus or over a communication network or a broadcast network).
  • a communication interface e.g. to a bus or over a communication network or a broadcast network.
  • bitstream F1 and the information data ID are transmitted over different communication interface (to different bus or over different communication network or broadcast network).
  • the information data and the bitstream F1 are transmitted in an asynchronous way.
  • Fig. 9 shows a block diagram of the substeps of the step 21 for decoding a bitstream representing LDR and the illumination pictures in accordance with an embodiment of the disclosure.
  • a decoder VDEC obtains a decoded frame SF by decoding a bitstream F1 at least partially.
  • a module IDD obtains an information data ID, possibly from the parameters Param and/or a local/remote memory.
  • the information data ID indicates that the decoded frame SF contains samples of at least two distinct packed constituent pictures according to a specific frame-packing- arrangement scheme FPAS.
  • the specific frame-packing-arrangement scheme FPAS is defined by the information data ID or obtained from a memory.
  • a module CH checks if the information data ID indicates that one of the at least two distinct packed constituent pictures corresponds to a LDR picture and another of the at least two distinct packed constituent pictures corresponds to an illumination picture.
  • a module UPACKM obtains from the decoded single frame SF both the LDR and the illumination pictures according to the specific frame-packing-arrangement scheme FPAS.
  • the LDR and the illumination pictures are then used, for example, for obtaining an HDR picture according to a method as defined, for example, by the information data ID.
  • the decoded picture is decoded according to decoding parameters which depend on the specific frame- packing-arrangement scheme FPAS.
  • the information data is a SEI message (Supplementary Enhancement Information message).
  • Fig. 10 shows an example of the syntax of such a SEI message which is relative to a frame-packing arrangement according to an embodiment of the disclosure.
  • the syntax of the SEI message is an extension of the syntax of the frame-packing-arrangement SEI message as defined by the above cited H.264 recommendation.
  • a new frame packing arrangement SEI message in addition to the existing one, can also be defined specifically for the HDR picture decoding process.
  • the frame-packing SEI message can also include the parameters related to the output HDR format, and to the module ISPLM that generates a decoded version / of the HDR picture I from the decoded version RF of the LDR picture RF and the decoded version IF of the illumination picture IF.
  • This new frame-packing SEI message would therefore merge the parameters related to the frame packing, and the parameters mentioned in Fig. 5 or 7.
  • the frame-packing-arrangement SEI message informs a decoder that an output decoded picture contains samples of multiple distinct spatially packed constituent pictures using an indicated frame-packing- arrangement scheme. This information can be used by the decoder to appropriately rearrange the samples and process the samples of the constituent pictures appropriately for display or other purposes.
  • the syntax of the SEI message in Fig. 10 is similar to the syntax given by the table of the section D.1 .25 of the cited H.264 recommendation (and also by HEVC recommendation).
  • Fig. 11 shows a table given an interpretation of the flag "content_interpretation_type" of Fig. 10.
  • the tag "content_interpretation_type” may be equal to three values (0-2) as defined in the cited ITU-T Recommendation H.264 (table D-10).
  • this tag may also be equal to a specific value (here 3) indicating that one of at least two distinct packed constituent pictures corresponds to an LDR picture and another of the at least two distinct packed constituent pictures corresponds to an HDR illumination picture associated with said LDR picture.
  • this specific value of the tag "content_interpretation_type" may further indicate a post-processing to be applied after the decoding of the frame SF in order, for example, to retrieve the HDR picture from the decoded LDR and the illumination pictures for example.
  • Fig. 12 shows a table given an interpretation of the flag "frame_packing_arrangement_type" of Fig. 10.
  • Each value of the flag defines a specific frame-packing-arrangement scheme.
  • the tag may be equal to height values (0-7) as defined in the cited H.264 recommendation (table D-9).
  • this tag may be equal to a specific value (here 8) to indicate that the LDR and the illumination pictures do not have a same size and/or have specific positions in the frame SF.
  • This tag may further indicate that different sizes and/or positions are defined by at least one additional flag.
  • the size of the LDR picture, respectively the illumination picture is defined by additional parameter in the SEI message while the size of the illumination picture, respectively the LDR picture, can be derived from the SPS (Sequence Parameters Set). Note the SPS contains the size of the picture SF.
  • a first additional flag 1 entitled “different_views_size_flag", is added in the syntax of the SEI message to indicate that the LDR and the illumination pictures do not have the same size and/or have specific position in the frame SF.
  • a set of additional parameters 2 is added in the syntax of the SEI message to indicate the size (width and height) of the LDR picture and of the size of the illumination picture: the value "pictureO_pic_width_in_luma_samples” indicates the number of columns of the pictureO from its top left corner, the value “pictureO_pic_height_in_luma_samples” indicates the number of rows of the pictureO from its top left corner, the flag “picture1_pic_width_in_luma_samples” indicates the number of columns of the picturel from its top left corner, and the flag “picture1_pic_height_in_luma_samples” indicates the number of rows of the picturel from its top left corner.
  • a set of additional parameters 3 is added in the syntax of the SEI message to indicate the position of the LDR picture and of the position of the illumination picture in the frame SF: the value
  • pictureO_offset_x_in_luma_samples indicates an offset from the first row of the picture SF
  • the value “pictureO_offset_y_in_luma_samples” indicates an offset from the first column of the frame SF
  • the value “picture1_offset_x_in_luma_samples” indicates an offset from the first row of the frame SF
  • the value “picture1_offset_y_in_luma_samples” indicates an offset from the first column of the frame SF.
  • the pictureO refers to the LDR picture, respectively to the illumination picture IF
  • the picturel refers to the illumination picture IF, respectively to the LDR picture.
  • the flag "picture_packing_arrangement_type" may be equal to a specific value to constrain an encoder to encode the frame SF according to a specific frame- packing-arrangement FPAS.
  • the encoder may be constrained to encode the frame SF slice by slice (as shown in Fig. 13, 14 or 15 for example) or to have tiles boundaries coinciding with the frame SF as shown in Fig. 14 and 15.
  • the flag "picture_packing_arrangement_type" indicates a specific frame-packing- arrangement scheme FPAS in which either the LDR picture and/or the illumination picture is split in several pieces.
  • the specific frame-packing- arrangement scheme FPAS further indicates the position of each piece in the frame SF.
  • Fig. 13 shows an example of such a frame-packing-arrangement scheme according to this embodiment.
  • the picturel (either the LDR picture or the illumination picture) is split into four slices (pieces) and the slices are located in the bottom of the picture SF.
  • Fig. 15 shows a variant of the frame-packing-arrangement scheme of the Fig. 14.
  • the scope of the disclosure is not limited to the disclosed frame- packing-arrangement schemes but extends to any frame-packing- arrangement scheme to pack two pictures in a single picture.
  • Fig. 16 shows a block diagram of the substeps of the step 10 in accordance with an embodiment of the disclosure.
  • a module IC obtains the luminance component L and potentially at least one color component C(i) of the HDR picture I to be encoded.
  • the luminance component L is obtained, for instance in the 709 gamut, by a linear combination which is given by:
  • a module BAM determines the illumination picture IF from the luminance component L of the HDR picture I.
  • a module Bl determines a backlight picture Ba as being a weighted linear combination of shape functions ⁇ given by:
  • L consists in finding optimal weighting coefficients (and potentially also optimal shape functions if not known beforehand) in order that the backlight picture Ba fits the luminance component L.
  • weighting coefficients a There are many well-known methods to find the weighting coefficients a,. For example, one may use a least mean square method to minimize the mean square error between the backlight picture Ba and the luminance component L.
  • shape functions may be the true physical response of a display backlight (made of LED's for instance, each shape function then corresponding to the response of one LED) or may be a pure mathematical construction in order to fit the luminance component at best.
  • the illumination picture IF output from step 162 is the backlight picture Ba given by equation (1 ).
  • a module BM modulates the backlight picture Ba (given by equation (1 )) with a mean luminance value L mean of the input HDR picture I obtained by the means of a module HL.
  • the illumination picture IF, output from step 162 is the modulated backlight picture.
  • the module HL is configured to calculate the mean luminance value L mean over the whole luminance component L.
  • the module HL is configured to calculate the mean luminance value L mean by
  • This last embodiment is advantageous because it avoids that the mean luminance value L mean be influenced by a few pixels with extreme high values which usually leads to very annoying temporal mean brightness instability when the HDR picture I belongs to a sequence of images.
  • the invention is not limited to a specific embodiment for calculating the mean luminance value L mean .
  • a module N normalizes the backlight image Ba (given by equation (1 )) by its mean value E(Ba) such that one gets a mid-gray-at-one backlight image B igray for the HDR picture (or for all HDR pictures if the HDR picture I belongs to a sequence of pictures):
  • the module BM is configured to modulate the mid-gray-at-one backlight image Ba gray with the mean luminance value L mean of the HDR picture I, by using the following relation
  • cst mod being a modulation coefficient and a being another modulation coefficient less than 1 , typically 1/3.
  • the illumination picture IF output from step 162
  • the modulated backlight image Ba mod given by equation (2).
  • the modulation coefficient cst mod is tuned to get a good looking brightness for the residual picture and highly depends on the process to obtain the backlight picture. For example, cst m0C i ⁇ 1 .7 for a backlight picture obtained by least means squares.
  • a residual picture Res is calculated by dividing the HDR picture I by a decoded version TP of the illumination picture IF.
  • the luminance component L and potentially each colour component C(i) of the HDR picture I, obtained from the module IC, is divided by the decoded version TP of the illumination picture IF. This division is done pixel per pixel.
  • the decoded version IF of the illumination picture IF is obtained by decoding at least partially the bitstream F1 by means of a decoder DEC (step 21 ) as described in relation with Fig. 2.
  • Fig. 20 shows a block diagram of the steps of a method in accordance with a variant of the method as described in Fig. 1 .
  • a module TMO tone-maps the residual picture Res, output of the step 10, in order to get a viewable LDR picture Res v .
  • the residual image Res may not be viewable because its dynamic range is too high and because a decoded version of this residual image Res shows too visible artifacts. Tone-mapping the residual image remedies to at least one of these drawbacks.
  • the invention is not limited to any specific tone-mapping operator. This single condition is that the tone-mapping operator shall be reversible.
  • the tone-mapping operator defined by Reinhard may be used ⁇ Reinhard, E., Stark, M., Shirley, P., and Ferwerda, J., ⁇ Photographic tone reproduction for digital images, " ACM Transactions on Graphics 21 (July 2002)), or Boitard, R., Bouatouch, K., Cozot, R., Thoreau, D., & Gruson, A. (2012). Temporal coherency for video tone mapping. In A. M. J. van Eijk, C. C. Davis, S. M. Hammel, & A. K. Majumdar (Eds.), Proc. SPIE 8499, Applications of Digital Image Processing (p. 84990D-84990D-10)).
  • tone mapping the residual picture Res comprises either a gamma correction or a SLog correction according to the pixel values of the residual picture.
  • the viewable LDR picture Res v is then given, for example, by:
  • ⁇ being a coefficient of a gamma curve equal, for example, to 1/2.4.
  • the viewable LDR picture Res v is given, for example, by:
  • a,b and c are coefficients of a SLog curve determined such that 0 and 1 are invariant, and the derivative of the SLog curve is continuous in 1 when prolonged by a gamma curve below 1 .
  • a,b and c are functions of the parameter y.
  • the parameter ⁇ of the gamma-Slog curve is encoded as a parameter Param. Applying a gamma correction on the residual picture Res, pulls up the dark regions but does not lower enough high lights to avoid burning of bright pixels.
  • the module TMO applies either the gamma correction or the SLog correction according to the pixel values of the residual picture Res.
  • the gamma correction is applied and otherwise the SLog correction is applied.
  • the viewable LDR picture Res v usually has a mean value more or less close to 1 depending on the brightness of the HDR picture I, making the use of the above gamma-Slog combination particularly efficient.
  • step 202 a module
  • SCA scales the residual picture Res or the viewable residual picture Res v before encoding (step 1 1 ) by multiplying each component of the residual picture Res or of the viewable LDR picture Res v by a scaling factor cst sca iing- The resulting LDR picture Res s is then given by
  • the scaling factor cst SC aiing is defined to map the values of the residual picture Res or of the viewable LDR picture Res v between from 0 to the maximum value 2 N -1 , where N is the number of bits allowed as input for the coding by an encoder used to encode the residual picture Res or the viewable LDR picture Res v .
  • a module CLI clips the residual picture Res, Res v or Res s before encoding to limit its dynamic range to a targeted dynamic range TDR which is defined, for example, according to the capabilities of an encoder used to encode the residual picture.
  • the resulting LDR picture Res c is given, for example, by:
  • Res c max(2 N , Res v ) or
  • the invention is not limited to such clipping (max(.)) but extends to any kind of clipping.
  • Ressc max(2 N , cst SC aiing*Res)
  • Ressc max(2 N , csts C aiing*Res v ) according to the embodiments of the method.
  • the residual picture RF is one of the residual pictures Res, Res v , Res s or Res c .
  • the illumination picture IF and the residual picture RF are then encoded by an encoder ENC (step 1 1 ) as described in relation with the Fig. 1 .
  • the tone-mapping and scaling of a residual picture is a parametric process. It may be noted that the parameters a, cst mod , cst scaling , Y, ⁇ may suit the content the best following the taste of an expert in post-production and color grading. Moreover, these parameters may be fixed or not and in the latter case they may be considered as being some parameters Param.
  • Fig. 21 shows a block diagram of the steps of a method in accordance with a variant of the method as described in Fig. 2. As explained above, a decoded version RF of the LDR picture RF and a decoded version TP of the illumination picture IF are obtained from the step 21 .
  • a decoded version / of the HDR picture I is obtained by multiplying the decoded version RF of the LDR picture RF by the decoded version TP of the illumination picture IF.
  • the parameters ⁇ and/or cst ⁇ ing are also obtained either from a local memory or from the module FDEC (step 20).
  • a module ISCA applied an inverse scaling to the decoded version RF of the LDR picture RF by dividing the decoded version RF of the LDR picture RF by the parameter cst ⁇ ing .
  • a module ITMO applied an inverse-tone-mapping to decoded version RF of the LDR picture RF by means of the parameters y.
  • the parameter ⁇ defines a gamma curve and the inverse-tone-mapping is just to find, from the gamma curve, the values which correspond to the pixel values of the decoded version RF of the LDR picture RF.
  • the decoded version RF of the LDR picture RF used in step 213 is thus either the decoded version RF of the LDR picture RF, output of the step 21 or an inverse-scaled version of it (output of step 21 1 ) or an inverse-tone- mapped version of it (output of step 212 without step 21 1 ) or an inverse- scaled-and-inverse-tone-mapped version of it (output of step 212 with step 21 1 ) according to some embodiments of the method.
  • the bitstream F1 may be stored on a local or remote memory and/or transmitted through a communication interface (e.g. to a bus or over a communication network or a broadcast network).
  • a communication interface e.g. to a bus or over a communication network or a broadcast network.
  • the bitstream F2 may be stored on a local or remote memory and/or transmitted through a communication interface (e.g. to a bus or over a communication network or a broadcast network).
  • the bitstreams F1 and F2 may be transmitted asynchronously.
  • bitstream F1 and F2 may be combined together to represent a single bitstream according to a variant of the present disclosure.
  • the decoders DEC, FDEC and VDEC are configured to decode data which have been encoded by the encoder ENC, FENC and VENC respectively.
  • the encoders ENC, FENC and VENC are not limited to a specific encoder (decoder) but when an entropy encoder (decoder) is required, an entropy encoder such as a Huffmann coder, an arithmetic coder or a context adaptive coder like Cabac used in h264/AVC or HEVC is advantageous.
  • the encoders ENC, FENC and VENC are not limited to a specific encoder which may be, for example, an image/video coder with loss like JPEG, JPEG2000, MPEG2, h264/AVC or HEVC.
  • the output LDR format is encoded in a SEI message (first message SE1 ) and the output HDR format is encoded in a VUI message (second syntax element SE2).
  • Fig. 22-23 show an example of a SEI message, for example called "LDR_video_info()", representing an output LDR format and an example of a VUI message, for example called “vui_parameters()", representing an output HDR format whose the syntax complies with the HEVC recommendation in accordance with an embodiment of the disclosure.
  • LDR_video_info() representing an output LDR format
  • VUI message for example called “vui_parameters()”
  • LDR_video_info() comprises tags, which actually defines the output LDR format:
  • LDR_video_cancel_flag 1 indicates that the SEI message "LDR_video_info()" cancels the persistence of any previous SE.I message "LDR_video_info()" in output order.
  • LDR_video_full_range_flag specifies the colour space used for the decoded version / of the HDR picture I, rather than the colour space used for the CVS.
  • LDR_video_full_range_flag specifies the colour space used for the decoded version / of the HDR picture I, rather than the colour space used for the CVS.
  • LDR_video_target_colour_primaries has the same semantics as specified in subclause E.2.1 of the above cited HEVC recommendation for the colour_primaries syntax element, except as follows: LDR_video_target_colour_primaries specifies the colour space used for the decoded version / of the HDR picture I, rather than the colour space used for the CVS. When LDR_video_target_colour_primaries is not present in the SEI message "LDR_video_info()", the value of LDR_video_target_colour_primaries is inferred to be equal to colour primaries.
  • LDR_video_target_transfer_characteristics has the same semantics as specified in subclause E.2.1 of the above cited HEVC recommendation for the transfer_characteristics syntax element, except as follows: LDR_video_target_transfer_characteristics specifies the colour space used for the decoded version / of the HDR picture I, rather than the colour space used for the CVS. When LDR_video_target_transfer_characteristics is not present in the SEI message "LDR_video_info()", the value of
  • LDR_video_target_transfer_characteristics is inferred to be equal to transfer characteristics.
  • LDR_video_target_matrix_coeffs has the same semantics as specified in subclause E.2.1 of the above cited HEVC recommendation for the matrix_coeffs syntax element, except as follows: LDR_video_target_matrix_coeffs specifies the colour space used for decoded version / of the HDR picture I, rather than the colour space used for the CVS. When LDR_video_target_matrix_coeffs is not present in the SEI message "LDR_video_info()", the value of
  • LDR_video_target_matrix_coeffs is inferred to be equal to matrix_coeffs.
  • the other tags of the SEI message "LDR_video_info()" provide information about parameters used by the module ISPLM to obtain the decoded version IF of the illumination picture IF used to obtain the decoded version / of the HDR picture I.
  • the semantics of these tags are similar to the semantics mentioned for the SEI message described in relation with Fig. 5.
  • Fig. 23 shows the example of the VUl message "vui_parameters()".
  • the semantics of the tags are similar to the semantics mentioned for the VUl message described in relation with Fig. 3, apart that the syntax elements are related to a HDR picture.
  • a specific syntax element "sample_format” is added in the VUl for allowing the support on non-integer format (floating point format).
  • the semantic of the syntax element "sample_format” is proposed to specify the format of the samples of the luma and chroma sample arrays of the decoded version / of the HDR picture I.
  • the tag "sample_format” in Fig. 23 equal to 0 in order to indicate that the samples are in integer format. Values greater than 0 for the flag "sample_format” are reserved for future use by ITU-T
  • the value of the tag "sample_format” is inferred to be equal to 0.
  • the tag "sample_format” equal to 1 to in order to indicate that the samples are in half-float format.
  • the modules are functional units, which may or not be in relation with distinguishable physical units. For example, these modules or some of them may be brought together in a unique component or circuit, or contribute to functionalities of a software. A contrario, some modules may potentially be composed of separate physical entities.
  • the apparatus which are compatible with the invention are implemented using either pure hardware, for example using dedicated hardware such ASIC or FPGA or VLSI, respectively « Application Specific Integrated Circuit » « Field- Programmable Gate Array » « Very Large Scale Integration » or from several integrated electronic components embedded in a device or from a blend of hardware and software components.
  • Fig. 24 represents an exemplary architecture of a device 240 which may be configured to implement a method described in relation with Fig. 1- 23.
  • Device 240 comprises following elements that are linked together by a data and address bus 241 :
  • microprocessor 242 which is, for example, a DSP (or Digital Signal Processor);
  • ROM Read Only Memory
  • RAM or Random Access Memory
  • the battery 246 is external to the device.
  • the word « register » used in the specification can correspond to area of small capacity (some bits) or to very large area (e.g. a whole program or large amount of received or decoded data).
  • ROM 243 comprises at least a program and parameters. Algorithm of the methods according to the invention is stored in the ROM 243. When switched on, the CPU 242 uploads the program in the RAM and executes the corresponding instructions.
  • RAM 244 comprises, in a register, the program executed by the CPU 242 and uploaded after switch on of the device 240, input data in a register, intermediate data in different states of the method in a register, and other variables used for the execution of the method in a register.
  • the implementations described herein may be implemented in, for example, a method or a 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 (for example, discussed only as a method or a device), the implementation of features discussed may also be implemented in other forms (for example a program).
  • An apparatus may be implemented in, for example, appropriate hardware, software, and firmware.
  • the methods may be implemented in, for example, an apparatus such as, 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”), and other devices that facilitate communication of information between end-users.
  • PDAs portable/personal digital assistants
  • the input HDR picture is obtained from a source.
  • the source belongs to a set comprising:
  • a local memory e.g. a video memory or a RAM (or Random Access Memory), a flash memory, a ROM (or Read Only Memory), a hard disk ;
  • a storage interface (245), e.g. an interface with a mass storage, a
  • RAM random access memory
  • flash memory a read-only memory
  • ROM read-only memory
  • optical disc an optical disc or a magnetic support
  • a communication interface (245), e.g. a wireline interface (for example a bus interface, a wide area network interface, a local area network interface) or a wireless interface (such as a IEEE
  • an picture capturing circuit e.g. a sensor such as, for example, a CCD (or Charge-Coupled Device) or CMOS (or Complementary Metal-Oxide-Semiconductor)).
  • the decoded picture / and/or IF is sent to a destination; specifically, the destination belongs to a set comprising:
  • a local memory e.g. a video memory or a RAM, a flash memory, a hard disk ;
  • a storage interface (245), e.g. an interface with a mass storage, a RAM, a flash memory, a ROM, an optical disc or a magnetic support;
  • a communication interface e.g. a wireline interface (for example a bus interface (e.g. USB (or Universal Serial Bus)), a wide area network interface, a local area network interface, a HDMI (High Definition Multimedia Interface) interface) or a wireless interface (such as a IEEE 802.1 1 interface, WiFi ® or a Bluetooth ® interface); and
  • a wireline interface for example a bus interface (e.g. USB (or Universal Serial Bus)
  • a wide area network interface e.g. USB (or Universal Serial Bus)
  • a wide area network interface e.g. USB (or Universal Serial Bus)
  • a local area network interface e.g. USB (or Universal Serial Bus)
  • HDMI High Definition Multimedia Interface
  • a wireless interface such as a IEEE 802.1 1 interface, WiFi ® or a Bluetooth ® interface
  • the bitstream F and the information data ID are sent to a destination.
  • the bitstream F and the information data ID or both are stored in a local or remote memory, e.g. a video memory (244) or a RAM (244), a hard disk (243).
  • either the bitstream F or the information data ID or both are sent to a storage interface (245), e.g. an interface with a mass storage, a flash memory, ROM, an optical disc or a magnetic support and/or transmitted over a communication interface (245), e.g. an interface to a point to point link, a communication bus, a point to multipoint link or a broadcast network.
  • the bitstream F and/or the information data ID is obtained from a source.
  • the bitstream and/or the information data ID is read from a local memory, e.g. a video memory (244), a RAM (244), a ROM (243), a flash memory (243) or a hard disk (243).
  • the bitstream and/or the information data ID is received from a storage interface (1405), e.g. an interface with a mass storage, a RAM, a ROM, a flash memory, an optical disc or a magnetic support and/or received from a communication interface (245), e.g. an interface to a point to point link, a bus, a point to multipoint link or a broadcast network.
  • device 240 being configured to implement an method described in relation with Fig. 1 , belongs to a set comprising:
  • a video server e.g. a broadcast server, a video-on-demand server or a web server.
  • device 240 being configured to implement a method described in relation with Fig. 2, belongs to a set comprising:
  • the device A comprises means which are configured to implement a method as described in relation with the Fig. 1 and the device B comprises means which are configured to implement a method as described in relation with Fig. 2.
  • the network is a broadcast network, adapted to broadcast still pictures or video pictures from device A to decoding devices including the device B.
  • Implementations of the various processes and features described herein may be embodied in a variety of different equipment or applications, particularly, for example, equipment or applications.
  • equipment examples include an encoder, a decoder, a post-processor processing output from a decoder, a pre-processor providing input to an encoder, a video coder, a video decoder, a video codec, a web server, a set-top box, a laptop, a personal computer, a cell phone, a PDA, and other communication devices.
  • the equipment may be mobile and even installed in a mobile vehicle.
  • a computer readable storage medium can take the form of a computer readable program product embodied in one or more computer readable medium(s) and having computer readable program code embodied thereon that is executable by a computer.
  • a computer readable storage medium as used herein is considered a non-transitory storage medium given the inherent capability to store the information therein as well as the inherent capability to provide retrieval of the information therefrom.
  • a computer readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. It is to be appreciated that the following, while providing more specific examples of computer readable storage mediums to which the present principles can be applied, is merely an illustrative and not exhaustive listing as is readily appreciated by one of ordinary skill in the art: a portable computer diskette; a hard disk; a read-only memory (ROM); an erasable programmable read-only memory (EPROM or Flash memory); a portable compact disc read-only memory (CD-ROM); an optical storage device; a magnetic storage device; or any suitable combination of the foregoing.
  • the instructions may form an application program tangibly embodied on a processor-readable medium.
  • Instructions may be, for example, in hardware, firmware, software, or a combination. Instructions may be found in, for example, an operating system, a separate application, or a combination of the two.
  • a processor may be characterized, therefore, as, for example, both a device configured to carry out a process and a device that includes a processor-readable medium (such as a storage device) having instructions for carrying out a process. Further, a processor-readable medium may store, in addition to or in lieu of instructions, data values produced by an implementation.
  • implementations may produce a variety of signals formatted to carry information that may be, for example, stored or transmitted.
  • the information may include, for example, instructions for performing a method, or data produced by one of the described implementations.
  • a signal may be formatted to carry as data the rules for writing or reading the syntax of a described embodiment, or to carry as data the actual syntax-values written by a described embodiment.
  • Such a signal may be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal.
  • the formatting may include, for example, encoding a data stream and modulating a carrier with the encoded data stream.
  • the information that the signal carries may be, for example, analog or digital information.
  • the signal may be transmitted over a variety of different wired or wireless links, as is known.
  • the signal may be stored on a processor-readable medium.
  • a number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. For example, elements of different implementations may be combined, supplemented, modified, or removed to produce other implementations. Additionally, one of ordinary skill will understand that other structures and processes may be substituted for those disclosed and the resulting implementations will perform at least substantially the same function(s), in at least substantially the same way(s), to achieve at least substantially the same result(s) as the implementations disclosed. Accordingly, these and other implementations are contemplated by this application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

La présente invention porte d'une manière générale à un procédé destiné à signaler, dans un train de bits représentant une image LDR et une image d'éclairage toutes deux obtenues à partir d'une image HDR, à la fois un format d'image/de vidéo d'une version décodée de ladite image LDR, appelé format LDR de sortie, et un format d'image/de vidéo d'une version décodée de ladite image HDR, appelé format HDR de sortie, le procédé comprenant le codage dans le train de bits d'un premier élément de syntaxe définissant le format LDR de sortie. Le procédé est caractérisé en ce qu'il comprend en outre le codage dans le train de bits d'un second élément de syntaxe qui est distinct du premier élément de syntaxe et qui définit le format HDR de sortie. L'invention concerne également un procédé/dispositif de codage/décodage, un produit programme d'ordinateur, un support lisible par un processeur, un support d'informations non transitoire et un signal.
PCT/EP2015/062473 2014-06-20 2015-06-04 Procédé et dispositif pour signaler dans un train de bits un format d'image/de vidéo d'une image ldr et un format d'image/de vidéo d'une image hdr décodée obtenue depuis ladite image ldr image et une image d'éclairage WO2015193114A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP14305966 2014-06-20
EP14305966.5 2014-06-20

Publications (1)

Publication Number Publication Date
WO2015193114A1 true WO2015193114A1 (fr) 2015-12-23

Family

ID=51162641

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/062473 WO2015193114A1 (fr) 2014-06-20 2015-06-04 Procédé et dispositif pour signaler dans un train de bits un format d'image/de vidéo d'une image ldr et un format d'image/de vidéo d'une image hdr décodée obtenue depuis ladite image ldr image et une image d'éclairage

Country Status (2)

Country Link
TW (1) TW201601524A (fr)
WO (1) WO2015193114A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2554663A (en) * 2016-09-30 2018-04-11 Apical Ltd Method of video generation

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1827024A1 (fr) * 2006-02-24 2007-08-29 Sharp Kabushiki Kaisha Codage d'images à gamme dynamique elevée
WO2011163114A1 (fr) * 2010-06-21 2011-12-29 Dolby Laboratories Licensing Corporation Affichage d'images sur des affichages à gradation locale
WO2012147010A1 (fr) * 2011-04-28 2012-11-01 Koninklijke Philips Electronics N.V. Procédé et appareil permettant de produire un signal de codage d'image
EP2579591A1 (fr) * 2011-10-04 2013-04-10 Thomson Licensing Procédé et dispositif pour coder une image HDR, procédé et dispositif de reconstruction d'une image HDR et support de stockage non transitoire

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1827024A1 (fr) * 2006-02-24 2007-08-29 Sharp Kabushiki Kaisha Codage d'images à gamme dynamique elevée
WO2011163114A1 (fr) * 2010-06-21 2011-12-29 Dolby Laboratories Licensing Corporation Affichage d'images sur des affichages à gradation locale
WO2012147010A1 (fr) * 2011-04-28 2012-11-01 Koninklijke Philips Electronics N.V. Procédé et appareil permettant de produire un signal de codage d'image
EP2579591A1 (fr) * 2011-10-04 2013-04-10 Thomson Licensing Procédé et dispositif pour coder une image HDR, procédé et dispositif de reconstruction d'une image HDR et support de stockage non transitoire

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
CHOI B ET AL: "MV-HEVC/SHVC HLS: Carriage of auxiliary pictures", 6. JCT-3V MEETING; 25-10-2013 - 1-11-2013; GENEVA; (THE JOINT COLLABORATIVE TEAM ON 3D VIDEO CODING EXTENSION DEVELOPMENT OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ); URL: HTTP://PHENIX.INT-EVRY.FR/JCT2/, no. JCT3V-F0048-v3, 21 October 2013 (2013-10-21), XP030131449 *
DAVID TOUZÉ ET AL: "HDR Video Coding based on Local LDR Quantization", HDRI2014 -SECOND INTERNATIONAL CONFERENCE AND SME WORKSHOP ON HDR IMAGING, 4 March 2014 (2014-03-04), XP055112158, Retrieved from the Internet <URL:http://people.irisa.fr/Ronan.Boitard/articles/2014/HDR Video Coding based on Local LDR Quantization.pdf> [retrieved on 20140404] *
GARY J SULLIVAN ET AL: "Overview of the High Efficiency Video Coding (HEVC) Standard", IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, vol. 22, no. 12, 1 December 2012 (2012-12-01), pages 1649 - 1668, XP011487803, ISSN: 1051-8215, DOI: 10.1109/TCSVT.2012.2221191 *
SEGALL A ET AL: "Tone mapping SEI Message", 19. JVT MEETING; 31-03-2006 - 07-04-2006; GENEVA, CH; (JOINT VIDEOTEAM OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ), no. JVT-S087, 1 April 2006 (2006-04-01), XP030006466, ISSN: 0000-0409 *
SULLIVAN (MICROSOFT) G J: "Edits reflecting decisions recorded for frame packing arrangement SEI messages and display/cropping windows", 11. JCT-VC MEETING; 102. MPEG MEETING; 10-10-2012 - 19-10-2012; SHANGHAI; (JOINT COLLABORATIVE TEAM ON VIDEO CODING OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ); URL: HTTP://WFTP3.ITU.INT/AV-ARCH/JCTVC-SITE/, no. JCTVC-K0382, 18 October 2012 (2012-10-18), XP030113264 *
TOUZE DAVID ET AL: "High dynamic range video distribution using existing video codecs", 2013 PICTURE CODING SYMPOSIUM (PCS), IEEE, 8 December 2013 (2013-12-08), pages 349 - 352, XP032566992, DOI: 10.1109/PCS.2013.6737755 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2554663A (en) * 2016-09-30 2018-04-11 Apical Ltd Method of video generation
US10462478B2 (en) 2016-09-30 2019-10-29 Apical Limited Method of video generation
GB2554663B (en) * 2016-09-30 2022-02-23 Apical Ltd Method of video generation

Also Published As

Publication number Publication date
TW201601524A (zh) 2016-01-01

Similar Documents

Publication Publication Date Title
US11178412B2 (en) Method and apparatus of encoding and decoding a color picture
JP7053722B2 (ja) ビットストリーム内で、ｌｄｒピクチャのピクチャ／ビデオ・フォーマットと、このｌｄｒピクチャおよびイルミネーション・ピクチャから取得された復号済みのｈｄｒピクチャのピクチャ／ビデオ・フォーマットとをシグナリングする方法および装置
US11006151B2 (en) Method and device for encoding both a HDR picture and a SDR picture obtained from said HDR picture using color mapping functions
US20180352257A1 (en) Methods and devices for encoding and decoding a color picture
EP3107301A1 (fr) Procédé et dispositif de codage d&#39;une trame hautement dynamique et cadre de plage imposé faiblement dynamique
EP3051489A1 (fr) Procédé et appareil de codage et de décodage d&#39;une image couleur
WO2015193113A1 (fr) Procédé et dispositif pour signaler dans un flux binaire un format d&#39;image/vidéo d&#39;une image ldr, et un format d&#39;image/vidéo d&#39;une image hdr décodée obtenu à partir de ladite image ldr et d&#39;une image d&#39;éclairage
US20180014024A1 (en) Method and apparatus of encoding and decoding a color picture
WO2015193114A1 (fr) Procédé et dispositif pour signaler dans un train de bits un format d&#39;image/de vidéo d&#39;une image ldr et un format d&#39;image/de vidéo d&#39;une image hdr décodée obtenue depuis ladite image ldr image et une image d&#39;éclairage
EP3099073A1 (fr) Procédé et dispositif de codage/décodage d&#39;une image hdr et sdr dans/à partir d&#39;un train binaire évolutif
EP2938083A1 (fr) Procédé et dispositif de traitement de données d&#39;informations indiquant qu&#39;une trame contient des échantillons d&#39;au moins deux trames constitutives conditionnées distinctes selon un schéma d&#39;arrangement de conditionnement de trame spécifique

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15725668

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15725668

Country of ref document: EP

Kind code of ref document: A1