Integrated image shaping and video encoding

Abstract

The present disclosure relates to integrated picture reshaping and video coding. Given a sequence of pictures represented in a first codeword representation, methods, processes and systems are proposed for integrating reshaping into next generation video codecs for encoding and decoding pictures, where reshaping allows encoding a portion of the picture in a second codeword representation that allows more efficient compression than using the first codeword representation. Various architectures are discussed, including: out-of-loop reshaping architecture, in-loop reshaping architecture for intra pictures only, in-loop architecture for prediction residuals, and hybrid in-loop reshaping architecture. Syntax methods for signaling reshaping parameters are also proposed, as well as picture encoding methods optimized with respect to reshaping.

Description

[0001] Division

[0002] This application is a divisional application of patent application number 201880012069.2, entered into the national phase in China on June 29, 2018, for the invention patent application entitled "Integrated Image Shaping and Video Coding," which is a PCT international application number PCT / US2018 / 040287, international filing date June 29, 2018.

[0003] Cross Reference to Related Applications

[0004] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 686,738, filed June 19, 2018, Serial No. 62 / 680,710, filed June 5, 2018, Serial No. 62 / 629,313, filed February 12, 2018, Serial No. 62 / 561,561, filed September 21, 2017, and Serial No. 62 / 526,577, filed June 29, 2017, each of which is incorporated by reference herein in its entirety. TECHNICAL FIELD

[0005] The present invention relates generally to image and video coding. More specifically, embodiments of the present invention relate to integrated image shaping and video coding. BACKGROUND

[0006] In 2013, the MPEG Expert Group in the International Standards Organization (ISO) published a draft of the HEVC (also known as H.265) video coding standard, along with the International Telecommunication Union (ITU). More recently, the MPEG Expert Group published a call for evidence to support the development of the next generation of coding standards that provide improved coding performance compared to existing video coding techniques.

[0007] As used herein, the term 'bit depth' refers to the number of bits used to represent one of the color components of a pixel of an image. Traditionally, images were encoded with 8 bits per pixel per color component (e.g., 24 bits per pixel); however, modern architectures can now support higher bit depths, such as 10 bits, 12 bits, or more.

[0008] In traditional image pipelines, a non-linear opto-electric function (OETF) is used to quantify captured images, which converts linear scene light into a non-linear video signal (e.g., gamma-encoded RGB or YCbCr). The signal is then processed on a receiver by an electro-optical transfer function (EOTF) before being displayed on a display, which translates video signal values into output screen color values. Such non-linear functions include the traditional "gamma" curves documented in ITU-R Rec. BT.709 and BT.2020, and the "PQ" (perceptual quantization) curves described in SMPTE ST 2084 and Rec. ITU-R BT.2100.

[0009] As used herein, the term "forward reshaping" denotes a sample-to-sample mapping or code word-to-code word mapping of a digital image from its original bit depth and original code word distribution or representation (e.g., gamma or PQ, etc.) to the same or different bit depth and different code word distribution or representation of the image. Reshaping allows for improved compressibility or improved image quality at a fixed bit rate. For example, without limitation, reshaping can be applied to 10-bit or 12-bit PQ encoded HDR video to improve coding efficiency in a 10-bit video coding architecture. In a receiver, after decompressing the reshaped signal, the receiver can apply an "inverse reshaping function" to restore the signal to its original code word distribution. As understood by the inventors herein, as development begins for the next generation of video coding standards, improved techniques for integrated reshaping and coding of images are desired. The methods of the present invention can be applicable to a variety of video content, including but not limited to content in standard dynamic range (SDR) and / or high dynamic range (HDR).

[0010] The methods described in this section are methods that can seek, but are not necessarily methods that have been previously conceived or sought. Accordingly, the methods described in this section should not be deemed to be prior art merely by virtue of their inclusion in this section. Similarly, unless otherwise indicated, problems identified in respect of any method should not be assumed to have been addressed in any prior art simply by virtue of their presentation in this section. SUMMARY

[0011] A first aspect of the present disclosure relates to a method for encoding an image with a processor, the method can include accessing, with a processor, an input image in a first codeword representation; generating a forward reshaping function that maps pixels of the input image to a second codeword representation, wherein the second codeword representation allows for more efficient compression than the first codeword representation; generating an inverse reshaping function based on the forward reshaping function, wherein the inverse reshaping function maps pixels from the second codeword representation to the first codeword representation; for an input pixel region in the input image; computing a prediction region based on pixel data in a reference frame buffer or in a spatial neighborhood of a previously encoded; generating a reshaped residual region based on the input pixel region, the prediction region, and the forward reshaping function; generating a quantized residual region based on the reshaped residual region; generating a dequantized residual region based on the quantized residual region; generating a reconstructed pixel region based on the dequantized residual region, the prediction region, the forward reshaping function, and the inverse reshaping function; and generating a reference pixel region to be stored on the reference frame buffer based on the reconstructed pixel region.

[0012] A second aspect of the present disclosure relates to a method for decoding an encoded bitstream with a processor to generate an output image in a first codeword representation, the method can include receiving an encoded image encoded in part in a second codeword representation, wherein the second codeword representation allows for more efficient compression than the first codeword representation; receiving reshaping information for the encoded image; generating a forward reshaping function that maps pixels from the first codeword representation to the second codeword representation based on the reshaping information; generating an inverse reshaping function based on the reshaping information, wherein the inverse reshaping function maps pixels from the second codeword representation to the first codeword representation; for a region of the encoded image; generating a decoded reshaped residual region; generating a prediction region based on pixels in a reference pixel buffer or in a spatial neighborhood of a previously decoded; generating a reconstructed pixel region based on the decoded reshaped residual region, the prediction region, the forward reshaping function, and the inverse reshaping function; generating an output pixel region of the output image based on the reconstructed pixel region; and storing the output pixel region in the reference pixel buffer.

[0013] A third aspect of the present disclosure relates to a method for decoding, with a processor, an encoded bitstream to generate an output image represented in a first codeword representation, the method can include receiving an encoded image encoded in part in a second codeword representation, wherein the second codeword representation allows for more efficient compression than the first codeword representation; receiving shaping information for the encoded image; generating a shaping scaling function based on the shaping information; generating, for a region of the encoded image; a decoded shaped residual region; generating a predicted region based on pixels in a reference pixel buffer or in a spatial neighborhood of previously decoded; generating a reconstructed pixel region based on the decoded shaped residual region, the predicted region, and the shaping scaling function; generating an output pixel region of the output image based on the reconstructed pixel region; and storing the output pixel region in the reference pixel buffer.

[0014] A fourth aspect of the present disclosure relates to a method for encoding, with a processor, an image, the method can include accessing, with a processor, an input image represented in a first codeword representation; selecting a shaping architecture from two or more candidate encoding architectures for compressing the input image in a second codeword representation, wherein the second codeword representation allows for more efficient compression than the first codeword representation, wherein the two or more candidate encoding architectures include an out-of-loop shaping architecture, an in-loop shaping architecture for intra frames only, and an in-loop architecture for prediction residuals; and compressing the input image according to the selected shaping architecture.

[0015] A fifth aspect of the present disclosure relates to a method for decoding, with a processor, an encoded bitstream to generate an output image represented in a first codeword representation, the method can include receiving an encoded bitstream including one or more encoded images, wherein at least a portion of an encoded image is represented in a second codeword representation, wherein the second codeword representation allows for more efficient compression than the first codeword representation; determining a shaping decoder architecture based on metadata in the encoded bitstream, wherein the shaping decoder architecture includes one of an out-of-loop shaping architecture, an in-loop shaping architecture for intra frames only, or an in-loop architecture for prediction residuals; receiving shaping information for an encoded image in the encoded bitstream; and decompressing the encoded image according to the shaping decoder architecture to generate the output image.

[0016] A sixth aspect of the present disclosure relates to an apparatus for image shaping, the apparatus can include one or more processors, and a memory having software instructions stored thereon that, when executed by the one or more processors, cause performance of a method according to the present disclosure.

[0017] A seventh aspect of the present disclosure relates to a non-transitory computer readable storage medium, which can have stored thereon computer executable instructions for performing a method according to the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0018] Embodiments of the application are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

[0019] FIG. 1A An example process depicting a video transmission pipeline is depicted;

[0020] FIG. 1B An example process depicting data compression using signal shaping according to the prior art is depicted;

[0021] FIG. 2A An example architecture of an encoder using out-of-loop shaping according to embodiments of the present application is depicted;

[0022] FIG. 2B An example architecture of a decoder using out-of-loop shaping according to embodiments of the present application is depicted;

[0023] FIG. 2C An example architecture of an encoder using intra-only in-loop shaping according to embodiments of the present application is depicted;

[0024] FIG. 2D An example architecture of a decoder using intra-only in-loop shaping according to embodiments of the present application is depicted;

[0025] FIG. 2E An example architecture of an encoder using in-loop shaping for prediction residuals according to embodiments of the present application is depicted;

[0026] FIG. 2F An example architecture of a decoder using in-loop shaping for prediction residuals according to embodiments of the present application is depicted;

[0027] FIG. 2G An example architecture of an encoder using hybrid in-loop shaping according to embodiments of the present application is depicted;

[0028] FIG. 2H An example architecture of a decoder using hybrid in-loop shaping according to embodiments of the present application is depicted;

[0029] FIG. 3A An example process for encoding a video using an out-of-loop shaping architecture according to embodiments of the present application is depicted;

[0030] FIG. 3BAn example process for encoding video using an in-loop only intra shaping architecture according to embodiments of the application is depicted;

[0031] FIG. 3C An example process for encoding video using an in-loop only intra shaping architecture according to embodiments of the application is depicted;

[0032] FIG. 3D An example process for decoding video using an in-loop only intra shaping architecture according to embodiments of the application is depicted;

[0033] FIG. 3E An example process for encoding video using an in-loop shaping architecture for prediction residuals according to embodiments of the application is depicted;

[0034] FIG. 3F An example process for decoding video using an in-loop shaping architecture for prediction residuals according to embodiments of the application is depicted;

[0035] FIG. 4A An example process for encoding video using any one or combination of the three shaping based architectures according to embodiments of the application is depicted;

[0036] FIG. 4B An example process for decoding video using any one or combination of the three shaping based architectures according to embodiments of the application is depicted;

[0037] FIG. 5A and FIG. 5B An example of a shaping function reconstruction process in a video decoder according to embodiments of the application is depicted;

[0038] FIG. 6A and FIG. 6B An example of how chroma QP offset values change according to luminance quantization parameters (QPs) of PQ encoded signals and HLG encoded signals according to embodiments of the application is depicted; and

[0039] FIG. 7 An example of a pivot based representation of a shaping function according to embodiments of the application is depicted. DETAILED DESCRIPTION

[0040] Described herein are out-of-loop and in-loop integrated signal shaping and coding techniques for compressing specifications of images. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present application. It will be apparent, however, that the present application can be practiced without these specific details. In other instances, well-known structures and devices are not described in exhaustive detail, in order to avoid unnecessarily

[0041] SUMMARY

[0042] Example embodiments described herein relate to signal shaping and encoding for integration of video. In an encoder, a processor receives an input image in a first codeword representation, the first codeword representation represented by an input bit depth N and an input codeword mapping (e.g., gamma, PQ, etc.). The processor selects an encoder architecture from two or more candidate encoder architectures for compressing the input image using a second codeword representation that allows more efficient compression than the first codeword representation (wherein a shaper is a component of the encoder), wherein the two or more candidate encoder architectures include an out-of-loop shaping architecture, an in-loop shaping architecture for intra pictures only, or an in-loop architecture for prediction residuals, and the processor compresses the input image according to the selected encoder architecture.

[0043] In another embodiment, a decoder for generating an output image in a first codeword representation receives an encoded bitstream, wherein at least a portion of the encoded image is compressed in a second codeword representation. The decoder also receives associated shaping information. A processor receives signaling indicating a decoder architecture from two or more candidate decoder architectures for decompressing the input encoded bitstream, wherein the two or more candidate decoder architectures include an out-of-loop shaping architecture, an in-loop shaping architecture for intra pictures only, or an in-loop architecture for prediction residuals, and the processor decompresses the encoded image according to the received shaping architecture to generate the output image.

[0044] In another embodiment, in an encoder for compressing an image according to an in-loop architecture for prediction residuals, a processor accesses an input image in a first codeword representation, and generates a forward shaping function that maps pixels of the input image from the first codeword representation to a second codeword representation. The processor generates, based on the forward shaping function, an inverse shaping function that maps pixels in the second codeword representation to pixels in the first codeword representation. Then, for an input pixel region in the input image, the processor:

[0045] computes at least one prediction region based on pixel data in a reference frame buffer or in a spatial neighborhood of a previously encoded;

[0046] generates a shaped residual region based on the input pixel region, the prediction region, and the forward shaping function;

[0047] generates an encoded (transformed and quantized) residual region based on the shaped residual region;

[0048] generates a decoded (inverse quantized and inverse transformed) residual region based on the encoded residual region;

[0049] generating a reconstructed pixel region based on the decoded residual region, the prediction region, the forward reshaping function, and the inverse reshaping function; and

[0050] generating a reference pixel region to be stored on a reference frame buffer based on the reconstructed pixel region.

[0051] In another embodiment, in a decoder for generating an output image in a first codeword representation from an in-loop architecture for predicting residuals, a processor receives an encoded bitstream encoded in a second codeword representation. The processor also receives associated reshaping information. The processor generates a forward reshaping function and an inverse reshaping function based on the reshaping information, where the forward reshaping function maps pixels from the first codeword representation to the second codeword representation and the inverse reshaping function maps pixels from the second codeword representation to the first codeword representation. For a region of the encoded image, the processor:

[0052] generating a decoded reshaped residual region based on the encoded image;

[0053] generating a prediction region based on pixels in the reference pixel buffer or in a spatial neighborhood previously decoded;

[0054] generating a reconstructed pixel region based on the decoded reshaped residual region, the prediction region, the forward reshaping function, and the inverse reshaping function;

[0055] generating an output pixel region based on the reconstructed pixel region; and storing the output pixel region in the reference pixel buffer.

[0056] Example video transmission processing pipeline

[0057] FIG. 1A An example process depicting a conventional video transmission pipeline (100) is shown, which illustrates various stages from video capture to display of video content. A sequence of video frames (102) is captured or generated using an image generation block (105). The video frames (102) can be digitally captured (e.g., by a digital camera) or generated by a computer (e.g., using computer animation) to provide video data (107). Alternatively, the video frames (102) can be captured on film by a film camera. The film is converted to a digital format to provide the video data (107). In a production stage (110), the video data (107) is edited to provide a video production stream (112).

[0058] The video data of the production stream (112) is then provided to a processor for post-production editing at block (115). The block (115) post-production editing can include adjusting or modifying the color or brightness in particular regions of the image to enhance the image quality or achieve a particular look of the image according to the creative intent of the video creator. This is sometimes referred to as "color timing" or "color grading." Other edits (e.g., scene selection and sequencing, image cropping, adding computer-generated visual effects, etc.) can be performed at block (115) to produce a final version (117) of the product for distribution. During the post-production editing (115), the video images are viewed on a reference display (125).

[0059] After post-production (115), the video data of the final product (117) can be transmitted to an encoding block (120) for downstream transmission to decoding and playback devices such as televisions, set-top boxes, movie theaters, etc. In some embodiments, the encoding block (120) can include audio and video encoders such as those defined by ATSC, DVB, DVD, Blu-ray, and other transmission formats to generate an encoded bitstream (122). In a receiver, the encoded bitstream (122) is decoded by a decoding unit (130) to generate a decoded signal (132) that is an exact or close approximation of the signal (117). The receiver can be attached to a target display (140) that can have completely different characteristics from the reference display (125). In this case, a display management block (135) can be used to map the dynamic range of the decoded signal (132) to the characteristics of the target display (140) by generating a display mapping signal (137).

[0060] Signal reshaping

[0061] FIG. 1BAn example process for signal shaping according to the prior art (Reference [1]) is depicted. Given an input frame (117), the forward shaping block (150) analyzes the input constraints and coding constraints and generates a codeword mapping function that maps the input frame (117) to a re-quantized output frame (152). For example, the input (117) can be coded according to some electro-optical transfer function (EOTF) (e.g., gamma). In some embodiments, information about the shaping process can be conveyed to downstream devices (such as decoders) using metadata. As used herein, the term "metadata" relates to any ancillary information that is transmitted as part of the encoded bitstream and that assists a decoder in rendering a decoded image. Such metadata can include, but is not limited to, color space or gamut information as described herein, reference display parameters, and auxiliary signal parameters.

[0062] After encoding (120) and decoding (130), the decoded frame (132) can be processed for further downstream processing, such as the display management process (135) discussed earlier, by a backward (or inverse) shaping function (160) that converts the re-quantized frame (132) back to the original EOTF domain (e.g., gamma). In some embodiments, the backward shaping function (160) can be integrated with the dequantizer in the decoder (130), for example, as part of the dequantizer in an AVC or HEVC video decoder.

[0063] As used herein, the term "shaper" can refer to either a forward shaping function or an inverse shaping function to be used when encoding and / or decoding a digital image. Examples of shaping functions are discussed in References [1] and [2]. For the purposes of the present invention, it is assumed that a person skilled in the art can derive suitable forward and inverse shaping functions from the characteristics of the input video signal and the available bit depth of the encoding and decoding architectures.

[0064] In Reference [1], a block-based in-loop image shaping method for high dynamic range video coding is proposed. This design allows for block-based shaping within the encoding loop, but at the cost of increased complexity. Specifically, the design requires maintaining two sets of decoded picture buffers: one for inverse-shaped (or non-shaped) decoded pictures that can be used for prediction without shaping and for output to a display; and another for forward-shaped decoded pictures that are only used for prediction with shaping. Although the forward-shaped decoded pictures can be computed in real-time, the complexity cost is very high, especially for inter-prediction (motion compensation with sub-pixel interpolation). Typically, display picture buffer (DPB) management is complex and requires a lot of care, and thus, as understood by the present inventors, a simplified method for encoding video is desired.

[0065] Embodiments of the codec architecture based on reshaping presented herein can be divided as follows: an architecture with an external out-of-loop reshaper, an architecture with an in-loop intra-only reshaper, and an architecture with an in-loop reshaper for the prediction residual (also referred to simply as ‘in-loop residual reshaper’). A video encoder or decoder can support any one of these architectures or a combination thereof. Each of these architectures can also be applied individually or in combination with any of the other architectures. Each architecture can be applied to the luminance component, the chrominance component, or a combination of luma and one or more chrominance components.

[0066] In addition to these three architectures, additional embodiments describe efficient signaling methods for the reshaping-related metadata and several encoder-based optimization tools to improve coding efficiency when applying reshaping.

[0067] Normed out-of-loop reshaper

[0068] FIG. 2A and FIG. 2B An architecture for a video encoder (200A_E) and a corresponding video decoder (200A_D) with a “normative” out-of-loop reshaper is depicted. The term “normative” indicates that, unlike previous designs where reshaping is considered a pre-processing step and is therefore outside the normative description of coding standards such as AVC, HEVC, etc., in this embodiment, the forward reshaping and inverse reshaping are part of the normative requirements. Unlike the architecture of FIG. 1B , where the bitstream conformance is tested according to the standard after decoding (130), in FIG. 2B , conformance is tested after the inverse reshaping block (265), e.g., at the output 162 in FIG. 1B .

[0069] In the encoder (200A_E), two new blocks are added to a traditional block-based encoder (e.g., HEVC): a block (205) to estimate the forward reshaping function, and a forward picture reshaping block (210) to apply the forward reshaping to one or more color components of the input video (117). In some embodiments, these two operations can be performed as part of a single image reshaping block. The parameters (207) related to the determination of the inverse reshaping function in the decoder can be passed to the lossless encoder block (e.g., CABAC 220) of the video encoder, so that they can be embedded into the encoded bitstream (122). The reshaped pictures stored in the DPB (215) are used to perform intra- or inter-prediction (225), transform and quantization (T and Q), inverse transform and inverse quantization (Q -1 and T -1) and all loop filtering related operations.

[0070] In the decoder (200A_D), two new normative blocks are added to the traditional block-based decoder: a block (250) for reconstructing the inverse reshaping function based on the encoded reshaping function parameters (207), and a block (265) for applying the inverse reshaping function to the decoded data (262) to generate the decoded video signal (162). In some embodiments, the operations related to blocks 250 and 265 can be combined into a single processing block.

[0071] FIG. 3A An example process (300A_E) for encoding a video using the out-of-loop reshaping architecture (200A_E) is depicted, according to embodiments of the present application. If reshaping is not enabled (path 305), the encoding proceeds as known in prior art encoders (e.g., HEVC). If reshaping is enabled (path 310), the encoder can have the option to either apply a predetermined (default) reshaping function (315), or to determine a new reshaping function (325) adaptively based on picture analysis (320), e.g., as described in references [1] to [3]. After forward reshaping (330), the rest of the encoding follows the traditional encoding pipeline (335). If adaptive reshaping (312) is employed, metadata related to the inverse reshaping function is generated as part of the “encode reshaper” step (327).

[0072] FIG. 3B An example process (300A_D) for decoding a video using the in-loop reshaping architecture (200A_D) is depicted, according to embodiments of the present application. If reshaping is not enabled (path 355), after the picture is decoded (350), the output frame is generated (390) as in the traditional decoding pipeline. If reshaping is enabled (path 360), in step (370), the decoder determines whether to apply a predetermined (default) reshaping function (375), or to determine the inverse reshaping function (380) adaptively based on the received parameters (e.g., 207). After inverse reshaping (385), the rest of the decoding follows the traditional decoding pipeline.

[0073] Normed in-loop intra-only reshaper

[0074] FIG. 2C An example architecture for an encoder (200B_E) using the normative intra-only in-loop reshaping is depicted, according to embodiments of the present application. The design is very similar to the one presented in reference [1]; however, to reduce complexity, especially when it comes to the use of DPB memory (215 and 260), only intra pictures are encoded using this architecture.

[0075] The main difference between the encoder 200B_E compared to the out-of-loop shaping (200A_E) is that the DPB (215) stores inverse shaped pictures instead of shaped pictures. In other words, the decoded intra picture needs to be inverse shaped (by inverse shaping unit 265) before it is stored in the DPB. The reason behind this approach is that if an intra picture is encoded with shaping, the improved performance of encoding the intra picture will propagate to (implicitly) improve the encoding of the inter pictures even if the inter pictures are not encoded with shaping. In this way, one can take advantage of shaping without the complexity of handling in-loop shaping for inter pictures. Since the inverse shaping (265) is part of the inner loop, it can be implemented before the in-loop filter (270). The advantage of adding inverse shaping before the in-loop filter is that in this case, the design of the in-loop filter can be optimized based on the characteristics of the original picture instead of the characteristics of the forward shaped picture.

[0076] FIG. 2D An example architecture of a decoder (200B_D) for using canonical intra-only in-loop shaping according to embodiments of the application is depicted. As FIG. 2D As depicted in

[0077] FIG. 3C An example process (300B_E) for encoding a video using an intra-only in-loop shaping architecture according to embodiments of the application is depicted. As depicted, FIG. 3C The operation flow in FIG. 3A shares many elements with the operation flow in FIG. 3D The main difference is that the shaping is not applied to inter coded pictures by default. For intra coded pictures, the encoder again has the option to use the default shaping curve or to apply adaptive shaping (312) if shaping is enabled. If the picture is shaped, inverse shaping (385) is part of the process and the associated parameters are encoded in step (327). In A corresponding decoding process (300B_D) is depicted in

[0078] FIG. 3D As depicted in

[0079] In-loop reshaper for prediction residuals

[0080] In coding, the term'residual' denotes the difference between a prediction of a sample or data element and its original or decoded value. For example, given an original sample (denoted as Orig_sample) from an input video (117), an intra- or inter-prediction (225) can generate a corresponding predicted sample (227) denoted as Pred_sample. If not reshaped, an un-reshaped residual (Res_u) can be defined as:

[0081] Res_u = Orig_sample - Pred_sample. (1)

[0082] In some embodiments, it can be beneficial to apply reshaping to the residual domain. FIG. 2E An example architecture of an encoder (200C_E) for using in-loop reshaping for predicting residuals is depicted in accordance with embodiments of the present application. Let Fwd() denote a forward reshaping function and let Inv() denote a corresponding inverse reshaping function. In embodiments, a reshaped residual (232) can be defined as:

[0083] Res_r = Fwd(Orig_sample) - Fwd(Pred_sample). (2)

[0084] Correspondingly, at the output (267) of the inverse reshaper (265), a reconstructed sample (267) denoted as Reco_sample can be expressed as:

[0085] Reco_sample = Inv(Res_d + Fwd(Pred_sample)), (3)

[0086] where Res_d denotes the residual (234) after in-loop encoding and decoding in 200C_E, i.e., an approximation of Res_r.

[0087] Note that, although reshaping is applied to the residuals, the actual input video pixels are not reshaped. FIG. 2F A corresponding decoder (200C_D) is depicted. Note that, as FIG. 2F depicted in and based on equation (3), the decoder needs access to both the forward reshaping function and the inverse reshaping function, which can be extracted using the received metadata (207) and the'reshaper decode' block (250).

[0088] In embodiments, in order to reduce complexity, equations (2) and (3) can be simplified. For example, assuming that the forward reshaping function can be approximated by a piecewise linear function and that the absolute difference between Pred_sample and Orig_sample is relatively small, equation (2) can be approximated as:

[0089] Res_r = a(Pred_sample) * (Orig_sample - Pred_sample), (4)

[0090] where a(Pred_sample) denotes a scaling factor based on the value of Pred_sample. According to equations (3) and (4), equation (3) can be approximated as:

[0091] Reco_sample = Pred_sample + (1 / a(Pred_sample)) * Res_r, (5)

[0092] Therefore, in an embodiment, only the scaling factor a(Pred_sample) for the piecewise linear model needs to be conveyed to the decoder.

[0093] FIG. 3E and FIG. 3F An example process flow for encoding (300C_E) and decoding (300C_D) a video using in-loop reshaping of prediction residuals is depicted. The processes are very similar to those described in FIG. 3A and FIG. 3B and thus need not be explained.

[0094] Table 1 summarizes the key features of the three proposed architectures.

[0095] Table 1: Key features of the considered reshaping architectures

[0096]

[0097] FIG. 4A and FIG. 4B An example encoding process flow and decoding process flow for encoding and decoding using a combination of the three proposed architectures is depicted. As FIG. 4A depicted in , if reshaping is not enabled, the input video is encoded according to known video encoding techniques (e.g., HEVC, etc.) without using any reshaping. Otherwise, the encoder can select any of the three main proposed methods according to the capabilities of the target receiver and / or input characteristics. For example, in an embodiment, the encoder can switch between these methods at a scene level, where a'scene' is denoted as a sequence of consecutive frames with similar brightness characteristics. In another embodiment, high-level parameters are defined at a sequence parameter set (SPS) level.

[0098] FIG. 4B As depicted in , the decoder can invoke any of the corresponding decoding processes according to the received reshaping information signaling for decoding the incoming encoded bitstream.

[0099] Hybrid in-loop reshaping

[0100] FIG. 2G An example architecture (200D_E) for an encoder using a hybrid in-loop reshaping architecture is depicted. This architecture combines elements from both the in-loop intra-only reshaping architecture (200B_E) and the in-loop residual architecture (200C_E) discussed earlier. Under this architecture, intra slices are encoded according to the in-loop intra-reshaping encoding architecture (e.g., 200B_E in FIG. 2), except with one difference: for intra slices, inverse picture reshaping (265-1) is performed after in-loop filtering (270-1). In another embodiment, in-loop filtering can be performed on intra slices after inverse reshaping; however, experimental results suggest that such an arrangement can yield worse coding efficiency compared to performing inverse reshaping after in-loop filtering. The rest of the operations remain the same as discussed earlier. FIG. 2C

[0101] As discussed earlier, inter slices are encoded according to the in-loop residual encoding architecture (e.g., 200C_E in FIG. 2). As depicted in FIG. 2, intra / inter slice switching allows switching between these two architectures depending on the type of slice to be encoded. FIG. 2E FIG. 2G As discussed earlier, inter slices are encoded according to the in-loop residual encoding architecture (e.g., 200C_E in FIG. 2). As depicted in FIG. 2, intra / inter slice switching allows switching between these two architectures depending on the type of slice to be encoded.

[0102] FIG. 2H An example architecture (200D_D) for a decoder using a hybrid in-loop reshaping is depicted. Again, intra slices are decoded according to the in-loop intra-reshaping decoder architecture (e.g., 200B_D in FIG. 2), where again for intra slices, in-loop filtering (270-1) precedes inverse picture reshaping (265-1). Inter slices are decoded according to the in-loop residual encoding architecture (e.g., 200C_D in FIG. 2). As depicted in FIG. 2, intra / inter slice switching allows switching between these two architectures depending on the type of slice in the encoded video picture. FIG. 2D FIG. 2F FIG. 2H As discussed earlier, inter slices are encoded according to the in-loop residual encoding architecture (e.g., 200C_E in FIG. 2). As depicted in FIG. 2, intra / inter slice switching allows switching between these two architectures depending on the type of slice to be encoded.

[0103] By invoking the encoding process 300D-E depicted in FIG. 3, FIG. 2G can be easily extended to also include a hybrid in-loop reshaping encoding method. Similarly, by invoking the decoding process 300D-D depicted in FIG. 3, FIG. 4A can be easily extended to also include a hybrid in-loop reshaping decoding method. FIG. 2H FIG. 4B

[0104] Slice-level reshaping

[0105] ​​​​​​Embodiments of the present application allow various adaptation at slice level. For example, in order to reduce the computation, reshaping can be enabled only for intra slices or only for inter slices. In another embodiment, reshaping can be allowed based on the value of the temporal ID (e.g. the variable Temporalld (reference

[11] ) of HEVC, where Temporalld = nuh_temporal_id_plusl - 1). For example, if the Temporalld of the current slice is less than or equal to a pre-defined value, the slice_reshaper_enable_flag of the current slice can be set to 1, otherwise, the slice_reshaper_enable_flag will be 0. In order to avoid sending the slice_reshaper_enable_flag parameter for each slice, the sps_reshaper_temporal_id parameter can be specified at SPS level, thus the value of the slice_reshaper_enable_flag parameter can be inferred.

[0106] For slices with reshaping enabled, the decoder needs to know which reshaping model to use. In one embodiment, the reshaping model defined at SPS level can be used always. In another embodiment, the reshaping model defined in the slice header can be used always. If no reshaping model is defined in the current slice, the reshaping model used in the last decoded slice with reshaping can be applied. In another embodiment, the reshaping model can be always specified in intra slices, regardless of whether reshaping is used for intra slices or not. In such implementation, the parameters slice_reshaper_enable_flag and slice_reshaper_model_present_flag need to be de-correlated. An example of such slice syntax is depicted in Table 5.

[0107] Signaling of reshaping information

[0108] The information related to forward and / or inverse reshaping can be present in different information layers, e.g. in the video parameter set (VPS), sequence parameter set (SPS), picture parameter set (PPS), slice header, supplemental information (SEI), or any other high level syntax. As an example and without limitation, Table 2 provides an example of high level syntax in SPS for signaling whether reshaping is enabled, whether the reshaping is adaptive, and which of the three architectures is being used.

[0109] Table 2: Example of reshaping information in SPS

[0110]

[0111] Additional information can also be carried in some other layer, such as in the slice header. The reshaping function can be described by a look-up table (LUT), piecewise polynomials, or other kinds of parametric models. The type of reshaping model used to convey the reshaping function can be signaled by an additional syntax element (e.g., reshaping_model_type flag). For example, consider a system that uses the following two different representations: model_A (e.g., reshaping_model_type = 0) represents the reshaping function as a set of piecewise polynomials (e.g., see reference [4]), while in model_B (e.g., reshaping_model_type = 1) the reshaping function is adaptively derived by assigning codewords to different luminance bands based on picture luminance characteristics and visual importance (e.g., see reference [3]). Table 3 provides an example of syntax elements in the slice header of a picture to assist the decoder in determining the appropriate reshaping model being used.

[0112] Table 3: Example syntax for reshaping signaling in slice header

[0113]

[0114] The following three tables describe alternative examples of bitstream syntax for signal reshaping at the sequence layer, slice layer, or coding tree unit (CTU) layer.

[0115] Table 4: Example of reshaping information in SPS

[0116]

[0117] Table 5: Example syntax for reshaping signaling in slice header

[0118]

[0119] Table 6: Example syntax for reshaping signaling in CTU

[0120]

[0121] For Tables 4-6, example semantics can be expressed as:

[0122] sps_reshaper_enable_flag equal to 1 specifies that a reshaper is used in the coded video sequence (CVS). sps_reshaper_enabled_flag equal to 0 specifies that a reshaper is not used in the CVS.

[0123] slice_reshaper_enable_flag equal to 1 specifies that the reshaper is enabled for the current slice. slice_reshaper_enable_flag equal to 0 specifies that the reshaper is not enabled for the current slice.

[0124] sps_reshaper_signal_type specifies the original codeword distribution or representation. As an example and not by way of limitation, sps_reshaper_signal_type equal to 0 specifies SDR (gamma); sps_reshaper_signal_type equal to 1 specifies PQ; and sps_reshaper_signal_type equal to 2 specifies HLG.

[0125] reshaper_CTU_control_flag equal to 1 specifies that the reshaper is allowed to be adapted for each CTU. reshaper_CTU_control_flag equal to 0 specifies that the reshaper is not allowed to be adapted for each CTU. When reshaper_CUT_control_flag is not present, the value shall be inferred to be 0.

[0126] reshaper_CTU_flag equal to 1 specifies that the reshaper is used for the current CTU. reshaper_CUT_flag equal to 0 specifies that the reshaper is not used for the current CTU. When reshaper_CTU_flag is not present, the value shall be inferred to be equal to slice_reshaper_enabled_flag.

[0127] sps_reshaper_model_present_flag equal to 1 specifies that sps_reshaper_model() is present in the SPS. sps_reshaper_model_present_flag equal to 0 specifies that sps_reshaper_model() is not present in the SPS.

[0128] slice_reshaper_model_present_flag equal to 1 specifies that slice_reshaper_model() is present in the slice header. slice_reshaper_model_present_flag equal to 0 specifies that slice_reshaper_model() is not present in the SPS. sps_reshaper_chromaAdj equal to 1 specifies that chroma QP adjustment is done using chroma DQP. sps_reshaper_chromaAdj equal to 2 specifies that chroma QP adjustment is done using chroma scaling.

[0129] sps_reshaper_ILF_opt indicates whether to apply in-loop filter in the original domain or reshaped domain for intra and inter slices. For example, a two-bit syntax is used, where the least significant bit refers to intra slices:

[0130]

[0131]

[0132] In some embodiments, this parameter can be adjusted at slice level. For example, in an embodiment, when slice_reshaper_enable_flag is set to 1, a slice can include slice_reshape_ILFOPT_flag. In another embodiment, in SPS, if sps_reshaper_ILF_opt is enabled, sps_reshaper_ILF_Tid parameter can be included. If the TemporalID of the current slice <= sps_reshaper_ILF_Tid and slice_reshaper_enable_flag is set to 1, apply in-loop filter in reshaped domain. Otherwise, apply in-loop filter in un-reshaped domain.

[0133] In Table 4, chroma QP adjustment is controlled at SPS level. In an embodiment, chroma QP adjustment can also be controlled at slice level. For example, in each slice, when slice_reshaper_enable_flag is set to 1, syntax element slice_reshape_chromaAdj_flag can be added. In another embodiment, in SPS, if sps_reshaper_chromaAdj is enabled, syntax element sps_reshaper_ChromaAdj_Tid can be added. If the TemporalID of the current slice <= sps_reshaper_ChromaAdj_Tid and slice_reshaper_enable_flag is set to 1, apply chroma adjustment. Otherwise, do not apply chroma adjustment. Table 4B depicts an example variation of Table 4 using the syntax described earlier.

[0134] Table 4B: Example syntax for reshaping signaling using temporal ID in SPS

[0135]

[0136] sps_reshaper_ILF_Tid specifies the highest TemporalID for which in-loop filters are applied to reshaped slices in the reshaping domain. sps_reshaper_chromaAdj_Tid specifies the highest TemporalID for which chroma adjustment is applied to reshaped slices.

[0137] In another embodiment, a reshaping model ID (e.g., reshape_model_id) can be used to define a reshaping model, e.g., as part of the slice_reshape_model() function. The reshaping model can be signaled at the SPS level, PPS level, or slice header level. If signaled in the SPS or PPS, the value of reshape_model_id can also be inferred from sps_seq_parameter_set_id or pps_pic_parameter_set_id. An example of how to use reshape_model_id for slices that do not carry slice_reshape_model() (e.g., slice_reshaper_model_present_flag is equal to 0) is shown in Table 5B below, which is a variation of Table 5.

[0138] Table 5B: Example syntax for reshaping signaling using reshape_model_id in slice header

[0139]

[0140] In the example syntax, the parameter reshape_model_id specifies the value of the reshape_model being used. The value of reshape_model_id shall be in the range of 0 to 15.

[0141] As an example of using the proposed syntax, consider an HDR signal coded using PQ EOTF, where reshaping is used at the SPS level, no specific reshaping is used at the slice level (the same reshaping is used for all slices), and CTU adaptation is allowed only for inter slices. Then:

[0142] sps_reshaper_signal_type = 1 (PQ);

[0143] sps_reshaper_model_present_flag = 1;

[0144] / / Note: For inter slices, slice_reshaper_enable_flag can be manipulated to enable and disable the reshaper.

[0145]

[0146] In another example, consider an SDR signal, where reshaping is applied only at slice level and only for intra slices. Inter slices are allowed CTU reshaping adaptation only. Then:

[0147]

[0148] At CTU level, in an embodiment, CTU level reshaping can be enabled based on luma characteristics of the CTU. For example, for each CTU, the average luma (e.g., CTU_avg_lum_value) can be computed, compared to one or more thresholds, and based on the results of these comparisons, it can be decided whether to turn on or off reshaping. For example,

[0149] If CTU_avg_lum_value < THR1, or

[0150] If CTU_avg_lum_value > THR2, or

[0151] If THR3 < CTU_avg_lum_value < THR4,

[0152] Then, for that CTU, reshaper_CTU_Flag = 1.

[0153] In an embodiment, instead of using the average luma, some other luma characteristic of the CTU can be used, such as the minimum luma, the maximum luma, or the average luma, the variance, etc. Chroma based characteristics of the CTU can also be applied, or luma and chroma characteristics can be combined with thresholds.

[0154] As mentioned before (e.g., with respect to FIG. 3A , FIG. 3B and FIG. 3CIn the steps described above, the implementation may support default or static shaping functions, or adaptive shaping. A "default shaper" can be used to execute predefined shaping functions, thus reducing the complexity of analyzing each image or scene when obtaining the shaping curve. In this case, it is not necessary to signal the inverse shaping function at the scene, image, or slice level. The default shaper can be implemented by using a fixed mapping curve stored in the decoder to avoid any signaling, or it can be signaled once as part of a sequence-level parameter set. In another embodiment, a previously decoded adaptive shaping function can be reused for subsequent images in the encoding order. In another embodiment, the shaping curve can be signaled in a manner different from the previously decoded method. In other embodiments (e.g., for in-loop residual shaping that requires both the Inv() and Fwd() functions to perform inverse shaping), only one of the Inv() or Fwd() functions can be signaled in the bitstream, or alternatively, both functions can be signaled to reduce decoder complexity. Tables 7 and 8 provide two examples of signaling shaping information.

[0155] In Table 7, the integer functions are transmitted as a set of second-order polynomials. This is a simplified syntax of the Exploratory Test Model (ETM) (Reference [5]). Earlier variants can also be found in Reference [4].

[0156] Table 7: Example syntax for piecewise representation of integer functions (model_A)

[0157]

[0158] reshape_input_luma_bit_depth_minus8 specifies the sample bit depth of the input luminance component in the reshaping process.

[0159] coeff_log2_offset_minus2 specifies the number of decimal places used for calculating the luminance component's shaped correlation coefficient.

[0160] The value of coeff_log2_offset_minus2 should be in the range of 0 to 3 (inclusive).

[0161] Incrementing `reshape_num_ranges_minus1` by 1 specifies the number of ranges in the piecewise integer function. If `reshape_num_ranges_minus1` does not exist, its value is presumed to be 0. `reshape_num_ranges_minus1` should be in the range of 0 to 7 (including the endpoints for the luminance component).

[0162] reshape_equal_ranges_flag equal to 1 specifies that the piecewise reshaping function is split into NumberRanges segments with almost equal length, and the length of each range is not explicitly signaled. reshape_equal_ranges_flag equal to 0 specifies that the length of each range is explicitly signaled.

[0163] reshape_global_offset_val is used to derive the offset value used to specify the start point of the 0th range.

[0164] reshape_range_val[i] is used to derive the length of the i-th range of the luma component.

[0165] reshape_continuity_flag specifies the continuity property of the reshaping function of the luma component. If reshape_continuity_flag is equal to 0, zero-order continuity is applied to the piecewise linear inverse reshaping function between consecutive pivot points. If reshape_continuity_flag is equal to 1, first-order smoothness is used to derive a complete second-order polynomial inverse reshaping function between consecutive pivot points.

[0166] reshape_poly_coeff_order0_int[i] specifies the integer value of the i-th 0th order polynomial coefficient of the luma component.

[0167] reshape_poly_coeff_order0_frac[i] specifies the fractional value of the i-th 0th order polynomial coefficient of the luma component.

[0168] reshape_poly_coeff_order1_int specifies the integer value of the 1st order polynomial coefficient of the luma component.

[0169] reshape_poly_coeff_order1_frac specifies the fractional value of the 1st order polynomial coefficient of the luma component.

[0170] Table 8 describes an example embodiment of an alternative parametric representation according to model_B (reference [3]) discussed earlier.

[0171] Table 8: Example syntax for parametric representation of reshaping function (model_B)

[0172]

[0173] In Table 8, in an embodiment, the syntax parameters can be defined as follows: reshape_model_profile_type specifies the distribution type to be used in the reshaper construction process.

[0174] reshape_model_scale_idx specifies the index value of the scale factor (denoted as ScaleFactor) to be used in the reshaper construction process. The value of ScaleFactor allows for improved control of the reshaping function to improve overall coding efficiency. Additional details on the use of this ScaleFactor are provided in relation to the discussion of the reshaping function reconstruction process (e.g., as depicted in FIG. 5A and FIG. 5B . By way of example and not limitation, the value of reshape_model_scale_idx should be in the range of 0 to 3, inclusive. In an embodiment, the mapping between scale idx and ScaleFactor as shown in the following table is given by:

[0175] ScaleFactor = 1.0 - 0.05 * reshape_model_scale_idx.

[0176] reshape_model_scale_idx ScaleFactor 0 1.0 1 0.95 2 0.9 3 0.85

[0177] In another embodiment, for a more efficient fixed-point implementation,

[0178] ScaleFactor = 1 - 1 / 16 * reshape_model_scale_idx.

[0179] reshape_model_scale_idx ScaleFactor 0 1.0 1 0.9375 2 0.875 3 0.8125

[0180] reshape_model_min_bin_idx specifies the minimum bin index to be used in the reshaper construction process.

[0181] The value of reshape_model_min_bin_idx should be in the range of 0 to 31, inclusive.

[0182] reshape_model_max_bin_idx specifies the maximum bin index to be used in the reshaper construction process.

[0183] The value of reshape_model_max_bin_idx should be in the range of 0 to 31, inclusive.

[0184] reshape_model_num_band specifies the number of frequency bands to be used in the reshaper construction process.

[0185] The value of reshape_model_num_band shall be in the range of 0 to 15, inclusive.

[0186] reshape_model_band_profile_delta[i] specifies the delta value to be used for adjusting the profile of the i-th band in the reshaper construction process. The value of reshape_model_band_profile_delta[i] shall be in the range of 0 to 1, inclusive.

[0187] Compared to reference [3], the syntax in table 8 is much more efficient by defining a set of "default profile types" (such as highlight, midtone and dark). In an embodiment, each type has a pre-defined visual band importance profile. The pre-defined bands and corresponding profiles can be implemented in the decoder as fixed values, or they can also be signaled using high-level syntax such as sequence parameter set. At the encoder, each image is first analyzed and classified into one of the profile types. The profile type is signaled by the syntax element "reshape_model_profile_type". In adaptive reshaping, to capture the full range of image dynamics, the default profile is further adjusted by a delta for each luma band or luma band subset. The delta values are derived based on the visual importance of the luma bands and are signaled by the syntax element "reshape_model_band_profile_delta".

[0188] In one embodiment, the delta values can only take values 0 or 1. At the encoder, the visual importance is determined by comparing the percentage of band pixels in the entire image to the percentage of band pixels within the "dominant band", where the dominant band can be detected using a local histogram. If the pixels within a band are concentrated in a small local box, then the band is likely to be visually important in that box. The counts of dominant bands are summed and normalized to form a meaningful comparison to obtain the delta value for each band.

[0189] In the decoder, the reshaper function reconstruction process has to be invoked to obtain the reshaping LUT based on the method described in reference [3]. Therefore, the complexity is higher compared to the simpler piecewise approximation model which only needs to evaluate a piecewise polynomial function to compute the LUT. The benefit of using the parametric model syntax is that the bitrate using the reshaper can be significantly reduced. For example, based on typical test content, the model depicted in table 7 requires 200 to 300 bits to signal the reshaper, while the parametric model (as shown in table 8) only uses about 40 bits.

[0190] In another embodiment, forward shaping lookup tables can be derived from a parametric model of the dQP values, as depicted in Table 9. For example, in an embodiment,

[0191] dQP = clip3(min, max, scale * X + offset),

[0192] where min and max represent the boundaries of the dQP, scale and offset are two parameters of the model, and X represents a parameter derived based on the signal luminance (e.g., the luminance value of a pixel, or for a block, a measure of the block luminance (e.g., its minimum, maximum, average, variance, standard deviation, etc.)). For example, non-limitingly,

[0193] dQP = clip3(-3, 6, 0.015 * X - 7.5).

[0194] Table 9: Example syntax for parametric representation (Model C) of the shaping function

[0195]

[0196] In an embodiment, the parameters in Table 9 can be defined as follows:

[0197] full_range_input_flag specifies the range of the input video signal. full_range_input_flag equal to 0 corresponds to a standard dynamic range input video signal. full_range_input_flag equal to 1 corresponds to a full range input video signal. When full_range_input_flag is not present, it is inferred to be equal to 0.

[0198] Note: As used herein, the term "full range video" means that the valid code words in the video are not "restricted." For example, for a 10-bit full range video, the valid code words are between 0 and 1023, where 0 is mapped to the lowest luminance level. In contrast, for a 10-bit "standard range video," the valid code words are between 64 and 940, and 64 is mapped to the lowest luminance level.

[0199] For example, the "full range" and "standard range" calculations can be computed as follows:

[0200] For the normalized luminance value Ey' in

[01] , encode in BD bits (e.g., BD = 10, 12, etc.):

[0201] Full range: Y = clip3(0, (1 « BD) - 1, Ey' * ((1 « BD) - 1))

[0202] Standard range: Y = clip3(0, (1 « BD) - 1, round(1 « (BD - 8) * (219 * Ey' + 16)))

[0203] This syntax is similar to the "video_full_range_flag" syntax in the HEVC VUI parameters as described in section E.2.1 of the HEVC (H.265) specification (reference

[11] ).

[0204] dQP_model_scale_int_prec_minus3 plus 3 specifies the number of bits used to represent dQP_model_scale_int. dQP_model_scale_int specifies the integer value of the dQP model scale.

[0205] dQP_model_scale_int_prec equal to 0 indicates that dQP_model_scale_int is not signaled and is inferred to be 0.

[0206] dQP_model_scale_int specifies the integer value of the dQP model scale.

[0207] dQP_model_scale_frac_prec_minus16 plus 16 specifies the number of bits used to represent dQP_model_scale_frac. dQP_model_scale_frac specifies the fractional value of the dQP model scale.

[0208] dQP_model_scale_frac specifies the fractional value of the dQP model scale.

[0209] The variable dQPModelScaleAbs is derived as follows:

[0210] dQPModelScaleAbs = dQP_model_scale_int « (dQP_model_scale_frac_prec_minus16 + 16) + dQP_model_scale_frac

[0211] dQP_model_scale_sign specifies the sign of the dQP model scale. When dQPModelScaleAbs is equal to 0, dQP_model_scale_sign is not signaled and it is inferred to be 0.

[0212] dQP_model_offset_int_prec_minus3 plus 3 specifies the number of bits used to represent dQP_model_offset_int. dQP_model_offset_int specifies the integer value of the dQP model offset.

[0213] dQP_model_offset_frac_prec_minus1 plus 1 specifies the number of bits used to represent dQP_model_offset_frac.

[0214] dQP_model_offset_frac specifies the fractional value of the dQP model offset.

[0215] The variable dQPModelOffsetAbs is derived as follows:

[0216] dQPModelOffsetAbs = dQP_model_offset_int « (dQP_model_offset_frac_prec_minus1 + 1) + dQP_model_offset_frac

[0217] dQP_model_offset_sign specifies the sign of the dQP model offset. When dQPModelOffsetAbs is equal to 0, dQP_model_offset_sign is not signaled and is inferred to be 0.

[0218] dQP_model_abs_prec_minus3 plus 3 specifies the number of bits used to represent dQP_model_max_abs and dQP_model_min_abs.

[0219] dQP_model_max_abs specifies the integer value of the dQP model maximum.

[0220] dQP_model_max_sign specifies the sign of the dQP model maximum. When dQP_model_max_abs is equal to 0, dQP_model_max_sign is not signaled and is inferred to be 0.

[0221] dQP_model_min_abs specifies the integer value of the dQP model minimum.

[0222] dQP_model_min_sign specifies the sign of the dQP model minimum. When dQP_model_min_abs is equal to 0, dQP_model_min_sign is not signaled and is inferred to be 0.

[0223] Decoding process for model C

[0224] Given the syntax elements of Table 9, the shaping LUT can be derived as follows.

[0225] The variable dQPModelScaleFP is derived as follows:

[0226] dQPModelScaleFP = ((1 - 2 * dQP_model_scale_sign) * dQPModelScaleAbs) « (dQP_model_offset_frac_prec_minus1 + 1).

[0227] The variable dQPModelOffsetFP is derived as follows:

[0228] dQPModelOffsetFP = ((1 - 2 * dQP_model_offset_sign) * dQPModelOffsetAbs) « (dQP_model_scale_frac_prec_minus16 + 16).

[0229] The variable dQPModelShift is derived as follows:

[0230] dQPModelShift = (dQP_model_offset_frac_prec_minus1 + 1) + (dQP_model_scale_frac_prec_minus16 + 16).

[0231] The variable dQPModelMaxFP is derived as follows:

[0232] dQPModelMaxFP = ((1 - 2 * dQP_model_max_sign) * dQP_model_max_abs) « dQPModelShift

[0233] The variable dQPModelMinFP is derived as follows:

[0234] dQPModelMinFP = ((1 - 2 * dQP_model_min_sign) * dQP_model_min_abs) « dQPModelShift.

[0235] for Y = 0: maxY / / e.g., for 10-bit video, maxY = 1023

[0236]

[0237] If (full_range_input_flag = = 0) / / if input is standard range video

[0238] For Y outside the standard range, i.e. Y = [0:63] and [940:1023], set slope[Y] = 0;

[0239] CDF[0] = slope[0];

[0240] for Y = 0:maxY-1

[0241] {

[0242] CDF[Y+1] = CDF[Y] + slope[Y]; / / CDF[Y] is the integral of slope[Y]

[0243] }

[0244] for Y = 0:maxY

[0245] {

[0246] FwdLUT[Y] = round(CDF[Y]*maxY / CDF[maxY]); / / round and normalize to get FwdLUT

[0247] }

[0248] In another embodiment, the forward reshaping function can be represented as a set of luminance pivot points (In Y) and their corresponding codewords (Out Y) as depicted in Table 10. To simplify coding, the input luminance range is described using a linear piecewise representation according to a sequence of starting pivot and equally spaced subsequent pivots. In FIG. 7 An example of a representation of the forward reshaping function for 10-bit input data is depicted in

[0249] Table 10: Example syntax for pivot-based representation (Model D) of reshaping function

[0250]

[0251] In an embodiment, the parameters in Table 10 can be defined as follows:

[0252] full_range_input_flag specifies the range of the input video signal. full_range_input_flag equal to 0 corresponds to a standard range input video signal. full_range_input_flag equal to 1 corresponds to a full range input video signal. When full_range_input_flag is not present, it is inferred to be equal to 0.

[0253] bin_pivot_start specifies the pivot value of the first equal-length bin (710). When full_range_input_flag is equal to 0, bin_pivot_start shall be greater than or equal to the minimum standard range input and shall be less than the maximum standard range input. (For example, for 10-bit SDR input, bin_pivot_start (710) shall be between 64 and 940.)

[0254] bin_cw_start specifies the mapped value of bin_pivot_start (710) (e.g., bin_cw_start = FwdLUT[bin_pivot_start]).

[0255] log2_num_equal_bins_minus3 plus 3 specifies the number of equal-length bins after the starting pivot (710). The variables NumEqualBins and NumTotalBins are defined as follows:

[0256] NumEqualBins = 1 « (log2_num_equal_bins_minus3 + 3)

[0257] if full_range_input_flag == 0

[0258] NumTotalBins = NumEqualBins + 4

[0259] else

[0260] NumTotalBins = NumEqualBins + 2

[0261] Note: Experimental results show that most forward reshaping functions can be represented using eight equal-length segments; however, complex reshaping functions can require more segments (e.g., 16 segments or more).

[0262] equal_bin_pivot_delta specifies the length of the equal-length bins (e.g., 720-1, 720-N). NumEqualBins * equal_bin_pivot_delta shall be less than or equal to the valid input range. (For example, if full_range_input_flag is 0, for 10-bit input, the valid input range shall be 940-64 = 876; if full_range_input_flag is 1, for 10-bit input, the valid input range shall be 0 to 1023.)

[0263] bin_cw_in_first_equal_bin specifies the number of mapped codewords in the first equal bin interval (720-1) (725). Bin_cw_delta_abs_prec_minus4 plus 4 specifies the number of bits used to represent bin_cw_delta_abs[i] for each subsequent equal interval.

[0264] bin_cw_delta_abs[i] specifies the value of bin_cw_delta_abs[i] for each subsequent equal bin interval. bin_cw_delta[i] (e.g., 735) is the difference in the number of codewords (e.g., 740) in the current equal bin interval i (e.g., 720-N) compared to the number of codewords (e.g., 730) in the previous equal bin interval i-1.

[0265] bin_cw_delta_sign[i] specifies the sign of bin_cw_delta_abs[i]. When bin_cw_delta_abs[i] is equal to 0, bin_cw_delta_sign[i] is not signaled and is inferred to be 0. The variable bin_cw_delta[i] = (1 - 2*bin_cw_delta_sign[i])*bin_cw_delta_abs[i]

[0266] Decoding process for model D

[0267] Given the syntax elements of Table 10, for 10-bit input, the shaping LUT can be obtained as follows: Define constants:

[0268] minIN = minOUT = 0;

[0269] maxIN = maxOUT = 2^BD - 1 = 1023 for 10-bit case / / BD = bit depth

[0270] minStdIN = 64 for 10-bit case

[0271] maxStdIN = 940 for 10-bit case

[0272] Step 1: For j = 0 to NumTotalBins, obtain pivot value In_Y[j]

[0273]

[0274] Step 2: For j = 0 to NumTotalBins, obtain mapping value Out_Y[j]

[0275]

[0276] bin_cw[j] = bin_cw[j-1] + bin_cw_delta[j-4]; / / bin_cw_delta[i] starts at idx 0

[0277]

[0278] bin_cw[j] = bin_cw[j-1] + bin_cw_delta[j-3]; / / bin_cw_delta[i] starts at idx 0

[0279] Step 3: Linear interpolation to obtain all LUT entries

[0280] Initialization: FwdLUT[]

[0281]

[0282] In general, reshaping can be turned on or off for each slice. For example, reshaping can be enabled only for intra slices and disabled for inter slices. In another example, reshaping can be disabled for inter slices with the highest temporal level. (Note: As an example, as used herein, temporal sub-layers can match the definition of temporal sub-layers in HEVC.) In defining the reshaper model, in one example, the reshaper model can be signaled only in the SPS, but in another example, the slice reshaper model can be signaled in the intra slice. Alternatively, the reshaper model can be signaled in the SPS and the slice reshaper model can be allowed to update the SPS reshaper model for all slices, or the slice reshaper model can be allowed to update the SPS reshaper model only for intra slices. For inter slices following an intra slice, the SPS reshaper model or the intra slice reshaper model can be applied.

[0283] As another example, FIG. 5A and 5B depicts a reshaping function reconstruction process in a decoder according to an embodiment. The process uses the methods described in this document and in reference [3], where the visual rating range is

[05] .

[0284] As FIG. 5A shown, first (step 510), the decoder extracts the reshape_model_profile_type variable and sets the appropriate initial frequency band distribution for each interval (steps 515, 520, and 525). For example, in pseudo code:

[0285] if (reshape_model_profile_type == 0) R[bi] = Rbright [b i ];

[0286] Otherwise, if (reshape_model_profile_type == 1) R[bi] = R dark [b i ];

[0287] Otherwise R[b i ]=R mid [b i ].

[0288] In step 530, the decoder uses the received reshape_model_band_profile_delta[bi] values ​​to adjust the distribution of each frequency band, as shown below:

[0289] for(i=0:reshape_model_num_band-1)

[0290] {R[b i ]=R[b]+reshape_model_band_profile_delta[b i ]}.

[0291] In step 535, the decoder propagates the adjusted value to each binprofile as follows: if bin[j] belongs to frequency band b i , R_bin[j]=R[b i ].

[0292] In step 540, the interval distribution is modified as follows:

[0293] If (j > reshape_model_max_bin_idx) or (j < reshape_model_min_bin_idx)

[0294] Then {R_bin[j]=0}.

[0295] In parallel, in steps 545 and 550, the decoder can extract parameters to compute the scaling factor value and candidate codewords for each bin[j], as follows:

[0296] ScaleFactor=1.0-0.05*reshape_model_scale_idx

[0297] CW_dft[j] = the codeword in the interval if the default integer type is used.

[0298] CW_PQ[j] = TotalCW / TotalNumBins.

[0299] In computing the ScaleFactor value, for fixed-point implementations, 1 / 16 = 0.0625 can be used instead of using a scale factor of 0.05.

[0300] Continuing FIG. 5B In step 560, the decoder begins codeword (CW) pre-assignment for each bin based on the bin distribution as follows:

[0301] If R_bin[j] = = 0, CW[j] = 0

[0302] If R_bin[j] = = 1, CW[j] = CW_dft[j] / 2;

[0303] If R_bin[j] = = 2, CW[j] = min(CW_PQ[j], CW_dft[j]);

[0304] If R_bin[j] = = 3, CW[j] = (CW_PQ[j] + CW_dft[j]) / 2;

[0305] If R_bin[j] > = 4, CW[j] = max(CW_PQ[j], CW_dft[j]);

[0306] In step 565, the total used codewords are computed and the codeword (CW) assignment is refined / completed as follows: CW used = Sum(CW[j]):

[0307] If CW used > TotalCW, rebalance CW[j] = CW[j] / (CW used / TotalCW);

[0308] Else

[0309]

[0310] Finally, in step 565, the decoder: a) generates a forward reshaping function (e.g., FwdLUT) by accumulating the CW[j] values, b) multiplies the ScaleFactor value with the FwdLUT values to form a final FwdLUT (FFwdLUT), and c) generates an inverse reshaping function InvLUT based on the FFwdLUT.

[0311] In fixed-point implementations, computing the ScaleFactor and FFwdLUT can be expressed as:

[0312] ScaleFactor = (1 « SF_PREC) - reshape_model_scale_idx

[0313] FFwdLUT = (FwdLUT * ScaleFactor + (1 « (FP_PREC + SF_PREC - 1))) » (FP_PREC + SF_PREC),

[0314] where SF_PREC and FP_PREC are predefined precision related variables (e.g., SF_PREC = 4 and FP_PREC = 14), "c = a « n" means a binary shift operation left shift n bits on a (or c = a * (2 n )), and "c = a » n" means a binary shift operation right shift n bits on a (or c = a / (2 n )).

[0315] Chroma QP derivation

[0316] Chroma coding performance is closely related to luma coding performance. For example, in AVC and HEVC, a table is defined to specify the relationship between quantization parameters (QPs) of luma and chroma components, or between luma and chroma. The specification also allows the use of one or more chroma QP offsets to define the QP relationship between luma and chroma more flexibly. When reshaping is used, luma values are modified, and therefore, the relationship between luma and chroma can also be modified. To maintain and further improve coding efficiency during reshaping, in embodiments, a chroma QP offset is derived based on the reshaping curve at the coding unit (CU) level. This needs to be performed at both the decoder and the encoder.

[0317] As used herein, the term "coding unit" (CU) refers to a coding block (e.g., macroblock, etc.). For example, without limitation, in HEVC, a CU is defined as "a luma sample coding block, two corresponding chroma sample coding blocks of a picture having three sample arrays, or a sample coding block of a monochrome picture or a picture coded using three separate color planes and syntax structures for coding samples."

[0318] In embodiments, a chroma quantization parameter (QP) (chromaQP) value can be derived as follows:

[0319] 1) Derive an equivalent luma dQP mapping, dQPLUT, based on the reshaping curve:

[0320] for CW = 0: MAX_CW_VALUE - 1

[0321] dQPLUT[CW] = -6*log2(slope[CW]);

[0322] where slope[CW] represents the slope of the forward reshaping curve at each CW (codeword) point, and MAX_CW_VALUE is the maximum codeword value for a given bit depth, e.g., for a 10-bit signal, MAX_CW_VALUE = 1024 (2 10 ).

[0323] Then, for each coding unit (CU):

[0324] 2) Calculate the average luma of the coding unit, denoted as AvgY:

[0325] 3) Calculate the chromaDQP value based on dQPLUT[], AvgY, reshaping architecture, inverse reshaping function Inv(), and slice type, as shown in Table 11 below:

[0326] Table 11: Example chromaDQP values according to reshaping architecture

[0327]

[0328] 4) Calculate chromaQP as:

[0329] chromaQP = QP_luma + chromaQPOffset + chromaDQP;

[0330] where chromaQPOffset represents the chroma QP offset, and QP_luma represents the luma QP of the coding unit. Note that the value of the chroma QP offset can be different for each chroma component (e.g., Cb and Cr), and the chroma QP offset value is conveyed to the decoder as part of the encoded bitstream.

[0331] In an embodiment, dQPLUT[] can be implemented as a pre-defined LUT. Suppose all codewords are divided into N intervals (e.g., N = 32), and each interval contains M = MAX_CW_VALUE / N codewords (e.g., M = 1024 / 32 = 32). When assigning new codewords for each interval, they can limit the number of codewords to 1 to 2*M, so they can pre-compute dQPLUT[1…2*M] and save the computation results as a LUT. This approach can avoid any floating-point computation or approximation of fixed-point computation. The approach can also save encoding / decoding time. For each interval, a fixed chromaQPOffset is used for all codewords in the interval. The DQP value is set equal to dQPLUT[L], where L is the number of codewords for the interval, where 1 ≤ L ≤ 2*M.

[0332] The dQPLUT values can be pre-computed as follows:

[0333] for i = 1 : 2*M

[0334] slope[i] = i / M;

[0335] dQPLUT[i] = -6*log2(slope[i]);

[0336] end

[0337] In computing dQPLUT[x], different quantization schemes can be used to obtain integer QP values, such as: round(), ceil(), floor() or a mix of them. For example, a threshold TH can be set and if Y < TH, floor() is used to quantize the dQP value, otherwise, when Y > TH, ceil() is used to quantize the dQP value. The use of such quantization schemes and the corresponding parameters can be pre-defined in the codec or can be signaled in the bitstream for adaptation. An example syntax that allows mixing the quantization scheme with a threshold as discussed earlier is shown below:

[0338]

[0339] The quant_scheme_signal_table() function can be defined at different levels of the shaping syntax (e.g., sequence level, slice level, etc.) as needed for adaptation.

[0340] In another embodiment, the chroma DQP values can be computed by applying a scaling factor to the residual signal in each coding unit (or more specifically, transform unit). This scaling factor can be a value that depends on the luma and can be computed a) numerically, e.g., as the first derivative (slope) of the forward shaping LUT (see, e.g., equation (6) in the next section), or b) computed as:

[0341]

[0342] When using dQP(x) to compute Slope(x), dQP can be kept in floating point precision without integer quantization. Alternatively, various different quantization schemes can be used to compute quantized integer dQP values. In some embodiments, such scaling can be performed at the pixel level rather than at the block level, where each chroma residual can be scaled by a different scaling factor that is derived using the co-located luma prediction value for that chroma sample. Thus,

[0343] Table 12: Example chroma dQP values using scaling for hybrid in-loop shaping architecture

[0344]

[0345] For example, if CSCALE_FP_PREC = 16

[0346] • Forward scaling: After generating the chroma residual, before transform and quantization:

[0347] C_Res = C_orig - C_pred

[0348] C_Res_scaled = C_Res * S + (1 « (CSCALE_FP_PREC - 1)) » CSCALE_FP_PREC

[0349] • Inverse scaling: After inverse chroma quantization and inverse transform, but before reconstruction:

[0350] C_Res_inv = (C_Res_scaled « CSCALE_FP_PREC) / S

[0351] C_Reco = C_Pred + C_Res_inv

[0352] where S is S_cu or S_px.

[0353] Note: In Table 12, the average luminance (AvgY) of the block is calculated before inverse reshaping is applied when calculating Scu. Alternatively, inverse reshaping can be applied before calculating the average luminance, e.g., Scu = SlopeLUT[Avg(Inv[Y])]. This alternative calculation order also applies to calculating the values in Table 11; i.e., calculating Inv(AvgY) can be replaced by calculating Avg(Inv[Y]) values. The latter approach can be considered more accurate but increases computational complexity.

[0354] Encoder optimization regarding reshaping

[0355] This section discusses various techniques to improve the coding efficiency of the encoder by jointly optimizing the reshaping parameters and the encoder parameters when reshaping is part of the standardization decoding process (as described in one of the three candidate architectures). In general, encoder optimization and reshaping have their own limitations in addressing the coding problem in different places. In traditional imaging and coding systems, there are two types of quantization: a) sample quantization in the baseband signal (e.g., gamma or PQ coding), and b) transform-related quantization (part of the compression). Reshaping sits in between them. Picture-based reshaping is usually updated based on the picture and only allows sample value mapping based on their luminance levels without considering any spatial information. In block-based codecs (such as HEVC), transform quantization (e.g., for luminance) is applied within a spatial block and can be adjusted spatially, so the encoder optimization method has to apply the same set of parameters to the entire block containing samples with different luminance values. As understood by the inventors and described herein, joint reshaping and encoder optimization can further improve the coding efficiency.

[0356] Inter / intra mode decision

[0357] In traditional coding, the inter / intra mode decision is based on computing a distortion function (dfunc()) between the original sample and the predicted sample. Examples of such functions include sum of squared error (SSE), sum of absolute difference (SAD), etc. In embodiments, such distortion metrics can be used using reshaped pixel values. For example, if the original dfunct() uses Orig_sample(i) and Pred_sample(i), then when reshaping is applied, dfunct() can use its corresponding reshaped values Fwd(Orig_sample(i)) and Fwd(Pred_sample(i)). This approach allows more accurate inter / intra mode decision, thus improving the coding efficiency.

[0358] Luma DQP with reshaping

[0359] In the JCTVC HDR Common Test Conditions (CTC) document (reference [6]), lumaDQP and chromaQPoffsets are two encoder settings for modifying the quantization (QP) parameters of the luma and chroma components to improve the HDR coding efficiency. In this invention, several new encoder algorithms are proposed to further improve the original proposal. For each lumaDQP adaptation unit (e.g., 64x64 CTU), a dQP value is calculated based on the average input luma value of the unit (as shown in Table 3 of reference [6]). The final quantization parameter QP for each coding unit within this lumaDQP adaptation unit should be adjusted by subtracting this dQP. The dQP mapping table is configurable in the encoder input configuration. This input configuration is denoted as dQP inp .

[0360] As discussed in references [6] and [7], in the existing coding scheme, the same lumaDQP LUT dQP inp is used for both intra and inter pictures. Intra and inter pictures can have different properties and quality characteristics. In this invention, it is proposed to adjust the lumaDQP setting based on the picture coding type. Therefore, in the encoder input configuration, there are two dQP mapping tables are configurable, and denoted as dQP in p Intra and dQP inpInter .

[0361] As discussed earlier, when using the in-loop intra reshaping method, since no reshaping is performed for inter pictures, it is important to apply some lumaDQP settings to inter coded pictures to achieve similar quality as if the inter pictures are reshaped by the same reshaper as for intra pictures. In one embodiment, the lumaDQP settings for inter pictures should match the characteristics of the reshaping curve for intra pictures.

[0362] Let

[0363] Slope(x) = Fwd'(x) = (Fwd(x+dx) - Fwd(x-dx)) / (2dx), (6)

[0364] denotes the first order derivative of the forward reshaping function, then in the embodiment, the automatically derived dQP auto (x) value can be calculated as follows:

[0365] If Slope(x) = 0, then dQP auto (x) = 0, otherwise

[0366] dQP auto(x) = 61og2(Slope(x)), (7)

[0367] where dQP auto (x) can be clipped within a reasonable range, e.g., [-6 6].

[0368] If luma DQP is enabled for intra pictures with reshaping (i.e., the external dQp inpIntra is set), then luma DQP for inter pictures should take this into account. In an embodiment, the final inter dQP auto (x) can be calculated by adding dQP inpIntra ( equation (7) ) from the reshaper to the dQP final setting for intra pictures. In another embodiment, to exploit intra quality propagation, the dQP final setting for inter pictures can be set to dQP auto or only set with a small increment (by setting dQP inpInter ) and added to dQP auto .

[0369] In an embodiment, the following general rules for setting luma dQP values can apply when reshaping is enabled:

[0370] (1) The luma dQP mapping table can be set independently for intra pictures and inter pictures (based on picture coding type);

[0371] (2) If a picture within the coding loop is in the reshaped domain (e.g., intra pictures in the in-loop intra reshaping architecture or all pictures in the out-of-loop reshaping architecture), then the input luma to delta QP mapping dQP inp needs to be translated to the reshaped domain dQP rsp as well. That is,

[0372] dQP rsp (x) = dQP inp [Inv(x)]. (8)

[0373] (3) If a picture within the coding loop is in the un-reshaped domain (e.g., inverse reshaped or un-reshaped, e.g., inter pictures in the in-loop intra reshaping architecture or all pictures in the in-loop residual reshaping architecture), then the input luma to delta QP mapping does not need to be translated and can be used directly.

[0374] (4) The auto inter delta QP derivation is only valid for the in-loop intra reshaping architecture. In this case, the actual delta QP for inter pictures is the sum of the auto-derived and the input value:

[0375] dQP final [x] = dQP [Inv(x)] + dQP [Inv(x)]. (9)inp [x] + dQP auto [x], (9)

[0376] and dQP final [x] can be clipped to a reasonable range, e.g., [-12 12];

[0377] (5) The luma-to-dQP mapping table can be updated in each picture, or when the shaping LUT changes. The actual dQP adaptation (obtaining the corresponding dQP for quantization of a block according to the average luma value of the block) can occur at the CU level (encoder configurable).

[0378] Table 13 summarizes the dQP settings for each of the three proposed architectures.

[0379] Table 13: dQP settings

[0380]

[0381] Rate-distortion optimization (RDO)

[0382] In the JEM 6.0 software (reference [8]), when lumaDQP is enabled, a pixel-based weighted distortion based on RDO (Rate-Distortion Optimization) is used. The weight table is fixed based on luma values. In an embodiment, the weight table should be adjusted adaptively based on the lumaDQP settings computed as proposed in the previous section. Two weights for the sum of squared error (SSE) and the sum of absolute difference (SAD) are proposed as follows:

[0383]

[0384]

[0385] The weights computed by equation (10a) or equation (10b) are based on the total weight of the final dQP, which includes both the input lumaDQP and the dQP from the forward shaping function. For example, based on equation (9), equation (10a) can be written as:

[0386]

[0387] The total weight can be separated into the weight computed by the input lumaDQP:

[0388]

[0389] and the weight from the shaping:

[0390]

[0391] When total dQPs are used to compute total weights by first computing weights from shaping, precision is lost due to clipping operation to obtain integer dQPs aut oInstead, using the slope function directly to compute weights from shaping can maintain higher weight precision, and thus is more advantageous.

[0392] The weight from input lumaDQP is denoted as W dQP . Let f'(x) denote the first derivative (or slope) of the forward shaping curve. In embodiments, the total weight takes into account both the dQP value and the shape of the shaping curve, so the total weight value can be expressed as:

[0393] weight total = Clip3(0.0, 30.0, W dQP , f'(x) 2 ). (11)

[0394] Similar approach can also be applied to chroma components. For example, in embodiments, for chroma, dQP[x] can be defined according to Table 13.

[0395] Interaction with other coding tools

[0396] In the presence of shaping, this section provides several examples of suggested changes needed for other coding tools. Interactions can exist for any possible existing or future coding tools to be included in the next generation video coding standard. The examples given below are not limiting. In general, the video signal domain (shaped, unshaped, inverse-shaped) during the encoding steps needs to be identified, and the operations processing the video signal at each step need to take into account the shaping effect.

[0397] Cross-component linear model prediction

[0398] In CCLM (Cross-Component Linear Model Prediction) (reference [8]), the predicted chroma samples pred L (i,j) can be obtained using the luma reconstructed signal rec c '(i,j):

[0399] pred c (i,j) = a rec L '(i,j) + β. (12)

[0400] When shaping is enabled, in an embodiment, it can be necessary to discriminate whether the luma reconstructed signal is in the shaped domain (e.g. out-of-loop shaper or in-loop intra-shaper) or in the unshaped domain (e.g. in-loop residual shaper). In one embodiment, the reconstructed luma signal can be implicitly used as is without any additional signaling or operations. In other embodiments, if the reconstructed signal is in the unshaped domain, the reconstructed luma signal can be converted into the unshaped domain as well, as follows:

[0401] pred c (i,j) = a - Inv(rec L '(i,j)) + β. (13)

[0402] In other embodiments, a bitstream syntax element can be added to signal which domain is desired (shaped or unshaped), which can be decided by a RDO process or can be based on decoded information, saving the overhead required for explicit signaling. The corresponding operation can be performed on the reconstructed signal based on the decision.

[0403] Shaper with residual prediction tool

[0404] In the HEVC range extension profile, the residual prediction tool is included. The chroma residual signal is predicted from the luma residual signal at the encoder side as:

[0405] Δr C (x,y) = r C (x,y) - (a x r' L (x,y)) » 3, (14)

[0406] and the chroma residual signal is compensated at the decoder side as:

[0407] r' C (x,y) = Δr' C (x,y) + (a x r' L (x,y)) » 3, (15)

[0408] where r c denotes the chroma residual sample at position (x,y), r' L denotes the reconstructed residual sample of the luma component, Δr c denotes the predicted signal using the inter-color prediction, Δr' C denotes the reconstructed signal after encoding and decoding of Δr c , and r' C denotes the reconstructed chroma residual.

[0409] When reshaping is enabled, it can be necessary to consider which luma residual to use for chroma residual prediction. In one embodiment, the "residual" (which can be reshaped or unreshaped based on the reshaper architecture) can be used as-is. In another embodiment, the luma residual can be forced to be in one domain (such as in the unreshaped domain) and appropriate mapping performed. In another embodiment, appropriate handling can be derived by the decoder, or appropriate handling can be explicitly signaled as previously described.

[0410] Reshaper with adaptive clipping

[0411] Adaptive clipping (reference [8]) is a new tool that is introduced to signal the original data range with respect to content dynamics and to perform adaptive clipping instead of fixed clipping (based on internal bit-depth information) at each step where clipping occurs in the compression workflow (e.g., in transform / quantization, in-loop filtering, output). Let

[0412] T clip = Clip pBD (T, bitdepth, C) = Clip3(min C , max C , T), (16)

[0413] where x = Clip3(min, max, c) means:

[0414]

[0415] and

[0416] • C is the component ID (typically Y, Cb, or Cr)

[0417] • min c is the clipping lower bound used in the current slice for component ID C

[0418] • max c is the clipping upper bound used in the current slice for component ID C

[0419] When reshaping is enabled, in an embodiment, it can be necessary to find out the domain the data stream is currently in and perform clipping correctly. For example, if clipping is processed in reshaped domain data, the original clipping boundaries need to be translated to the reshaped domain:

[0420] T clip = Clip BD (T, bitdepth, C) =

[0421] = Clip3(Fwd(min C ), Fwd(max C ), T). (17)

[0422] Typically, each clipping step needs to be handled correctly with respect to the reshaping architecture.

[0423] Reshaper and in-loop filtering

[0424] In HEVC and JEM 6.0 software, in-loop filters such as ALF and SAO need to use reconstructed luma samples and uncompressed "original" luma samples to estimate the best filter parameters. When reshaping is enabled, in embodiments, the domain in which filter optimization is desired to be performed can be specified (explicitly or implicitly). In one embodiment, filter parameters on the reshaped domain can be estimated (with respect to the original, when reconstruction is in the reshaped domain). In other embodiments, filter parameters on the un-reshaped domain can be estimated (with respect to the original, when reconstruction is in the un-reshaped domain or in the inverse reshaped domain).

[0425] For example, depending on the in-loop reshaping architecture, in-loop filter optimization (ILFOPT) options and operations can be described by Table 14 and Table 15.

[0426] Table 14. In-loop filter optimization in in-loop intra-reshaping only architecture and in-loop mixed reshaping

[0427]

[0428]

[0429]

[0430] Table 15. In-loop filter optimization in in-loop residual reshaping architecture

[0431]

[0432] While most of the detailed discussion herein relates to methods performed on luma components, those skilled in the art will appreciate that similar methods can be performed on chroma color components and chroma related parameters such as chroma QP offset (see, for example, reference [9]).

[0433] In-loop reshaping and region of interest (ROI)

[0434] In the context of a given image, the term'region of interest' (ROI) as used herein denotes an image region that is considered to be of particular interest. In this section, novel embodiments are presented that only support in-loop reshaping of regions of interest. That is, in embodiments, reshaping can only be applied inside the ROI and not outside. In another embodiment, different reshaping curves can be applied in the region of interest and outside the region of interest.

[0435] The use of ROIs is motivated by the need to balance bit rate with image quality. For example, consider a video sequence of a sunset. In the upper half of the image, the sun can be located on a sky that is relatively uniform in color (so the pixels in the sky background can have a very low variance). In contrast, the lower half of the image can depict moving waves. From the viewer's perspective, it can be considered that the upper part is much more important than the lower part. On the other hand, the moving waves are difficult to compress since the pixels of the moving waves have a large variance, and each pixel requires more bits; however, it can be desirable to allocate more bits on the sun part than on the wave part. In this case, the upper half can be denoted as a region of interest.

[0436] ROI description

[0437] Most codecs today (e.g., AVC, HEVC, etc.) are block-based. To simplify implementation, a region can be specified in units of a block. Without limitation, using HEVC as an example, a region can be defined as a number of coding units (CU) or coding tree units (CTU). One or multiple ROIs can be specified. Multiple ROIs can be different or overlapping. The ROI is not necessarily rectangular. Syntax for ROIs can be provided at any level of interest, such as slice level, picture level, video stream level, etc. In an embodiment, the ROI is specified first in the sequence parameter set (SPS). Then in the slice header, small changes in the ROI can be allowed. Table 16 depicts an example of syntax where one ROI is specified as multiple CTUs in a rectangular region. Table 17 describes syntax for a modified ROI at the slice level.

[0438] Table 16: SPS syntax for ROI

[0439]

[0440] Table 17: Slice header syntax for ROI

[0441]

[0442] sps_reshaper_active_ROI_flag is equal to 1, specifying that there is a ROI in the coded video sequence (CVS). sps_reshaper_active_ROI_flag is equal to 0, specifying that there is no ROI in the CVS.

[0443] reshaper_active_ROI_in_CTUsize_left, reshaper_active_ROI_in_CTUsize_right, reshaper_active_ROI_in_CTUsize_top, and reshaper_active_ROI_in_CTUsize_bottom each specify the picture samples in the ROI according to the rectangular region specified in picture coordinates. For left and top, the coordinates are equal to offset*CTUsize, while for right and bottom, the coordinates are equal to offset*CTUsize - 1.

[0444] reshape_model_ROI_modification_flag equal to 1 specifies that the ROI is modified in the current slice. reshape_model_ROI_modification_flag equal to 0 specifies that the ROI is not modified in the current slice.

[0445] reshaper_ROI_mod_offset_left, reshaper_ROI_mod_offset_right, reshaper_ROI_mod_offset_top, and reshaper_ROI_mod_offset_bottom each specify the left / right / top / bottom offset values from reshaper_active_ROI_in_CTUsize_left, reshaper_active_ROI_in_CTUsize_right, reshaper_active_ROI_in_CTUsize_top, and reshaper_active_ROI_in_CTUsize_bottom.

[0446] For multiple ROIs, the example syntax for a single ROI in Table 16 and Table 17 can be extended using an index (or ID) for each ROI, similar to the scheme used in HEVC for defining multiple pan-scan rectangles using an SEI message (see HEVC specification, reference

[11] , section D.2.4).

[0447] ROI handling in in-loop intra-only reshaping

[0448] For intra-only reshaping, the ROI part of the picture is first reshaped, and then encoding is applied to it. Since reshaping is only applied to the ROI, it is possible to see the boundary between the ROI part and the non-ROI part of the picture. Since the in-loop filters (e.g., FIG. 2C or FIG. 2DThe ROI in 270) can span across the boundary, thus special care must be taken for the in-loop filter optimization (ILFOPT) for the ROI. In an embodiment, it is proposed to apply the in-loop filter only if the entire decoded picture is in the same domain. That is, the entire picture is either all in the reshaped domain or all in the un-reshaped domain. In one embodiment, at the decoder side, if the in-loop filter is applied on the un-reshaped domain, the inverse reshaping should be applied first on the ROI part of the decoded picture, and then the in-loop filter is applied. Next, the decoded picture is stored into the DPB. In another embodiment, if the in-loop filter is applied on the reshaped domain, the reshaping should be applied first on the non-ROI part of the decoded picture, and then the in-loop filter is applied, and then inverse reshaping is applied on the entire picture. Next, the decoded picture is stored into the DPB. In yet another embodiment, if the in-loop filter is applied on the reshaped domain, the inverse reshaping can be applied first on the ROI part of the decoded picture, then reshaping is applied on the entire picture, then the in-loop filter is applied, and then inverse reshaping is applied on the entire picture. Next, the decoded picture is stored into the DPB. The three approaches are summarized in Table 18. From the computation point of view, approach “A” is simpler. In an embodiment, the enablement of the ROI can be used to specify the order of performing inverse reshaping and in-loop filtering (LF). For example, if the ROI is actively used (e.g., SPS syntax flag = true), the LF (block 270) in FIG. 2C and FIG. 2D is performed after the inverse reshaping (block 265) in FIG. 2C and FIG. 2D If the ROI is not actively used, the LF is performed before the inverse reshaping.

[0449] Table 18. In-loop filtering (LF) options using ROI

[0450]

[0451]

[0452] ROI handling in in-loop prediction residual reshaping

[0453] For the in-loop (prediction) residual reshaping architecture (e.g., see 200C_D in FIG. 2F At the decoder, the processing can be expressed as:

[0454] If (current CTU belongs to ROI)

[0455] Reco_sample = Inv(Res_d + Fwd(Pred_sample)), (see equation (3))

[0456] Else

[0457] Reco_sample = Res_d + Pred_sample

[0458] End

[0459] ROI and encoder considerations

[0460] In the encoder, it is necessary to check whether each CTU belongs to the ROI. For example, for in-loop prediction residual shaping, a simple check based on equation (3) can perform the following:

[0461] If (current CTU belongs to the ROI)

[0462] Apply weighted distortion in RDO for luma. The weight is obtained based on equation (10)

[0463] Else

[0464] Apply unweighted distortion in RDO for luma

[0465] End

[0466] An example encoding workflow that takes into account the ROI during shaping can include the following steps:

[0467] - For intra picture:

[0468] - Apply forward shaping on the ROI region of the original picture

[0469] - Encode the intra frame

[0470] - Apply inverse shaping on the ROI region of the reconstructed picture before the loop filter (LF)

[0471] - Perform loop filtering in the unshaped domain (e.g., see method “C” in Table 18), which includes the following steps:

[0472] • Apply forward shaping on the non-ROI region of the original picture (so that the whole original picture is shaped for the loop filter reference)

[0473] • Apply forward shaping on the whole picture region of the reconstructed picture

[0474] • Obtain loop filter parameters and apply loop filtering

[0475] • Apply inverse shaping on the whole picture region of the reconstructed picture and store it in the DPB On the encoder side, since the LF needs to have a non-compressed reference picture for filter parameter estimation, the processing of the LF reference for each method is as shown in Table 19:

[0476] Table 19. Processing of the LF reference with respect to the ROI

[0477]

[0478] - For inter pictures:

[0479] - When encoding inter frames, for each CU inside the ROI, apply prediction residual shaping and weighting distortion for luma; for each CU outside the ROI, do not apply any shaping

[0480] - Perform loop filter optimization (option 1) as before (as if no ROI is used):

[0481] • Forward shaping on the entire picture region of the original picture

[0482] • Forward shaping on the entire picture region of the reconstructed picture

[0483] • Get loop filter parameters and apply loop filtering

[0484] • Apply inverse shaping on the entire picture region of the reconstructed picture and store it in the DPB

[0485] Reshaping for HLG coded content

[0486] The term Hybrid Log-Gamma or HLG refers to another transfer function defined in Rec. BT.2100 for mapping high dynamic range signals. The development of HLG was to maintain backward compatibility with legacy standard dynamic range signals encoded using legacy gamma functions. When comparing the codeword distribution between PQ encoded content and HLG encoded content, the PQ mapping tends to allocate more codewords in the dark and bright regions, while most HLG content codewords appear to be allocated into the middle range. HLG luma shaping can be performed using two methods. In one embodiment, the HLG content can simply be converted to PQ content and then all the PQ related shaping techniques discussed earlier can be applied. For example, the following steps can be applied:

[0487] 1) Map the HLG luma (e.g., Y) to PQ luma. Let the function or LUT of the transformation be denoted as HLG2PQ LUT(Y)

[0488] 2) Analyze the PQ luma values and get the PQ based forward shaping function or LUT. Denote it as PQAdpFLUT(Y)

[0489] 3) Combine the two functions or LUTs into a single function or LUT: HLGAdpFLUT[i] = PQAdpFLUT

[0490] [HLG2PQ LUT[i]].

[0491] Since the HLG codeword distribution is quite different from the PQ codeword distribution, this approach can produce sub-optimal reshaping results. In another embodiment, the HLG reshaping function is derived directly from the HLG samples. The same framework as used for the PQ signal can be applied, but the CW_Bins_Dft table is changed to reflect the characteristics of the HLG signal. In an embodiment, using the mid-tone distribution for the HLG signal, several CW_Bins_Dft tables can be designed according to user preference. For example, when it is preferred to preserve highlights, for alpha = 1.4,

[0492] g_DftHLGCWBin0 = {8, 14, 17, 19, 21, 23, 24, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 36, 37, 38, 39, 39, 40, 41, 41, 42, 43, 43, 44, 44, 30}.

[0493] When it is preferred to preserve mid-tones (or mid-range):

[0494] g_DftHLGCWBin1 = {12, 16, 16, 20, 24, 28, 32, 32, 32, 32, 36, 36, 40, 44, 48, 52, 56, 52, 48, 44, 40, 36, 36, 32, 32, 32, 26, 26, 20, 16, 16, 12}.

[0495] When it is preferred to preserve skin tones:

[0496] g_DftHLGCWBin2 = {12, 16, 16, 24, 28, 32, 56, 64, 64, 64, 64, 56, 48, 40, 32, 32, 32, 32, 32, 32, 28, 28, 24, 24, 20, 20, 20, 20, 20, 16, 16, 12};

[0497] From the bitstream syntax point of view, in order to distinguish between PQ-based reshaping and HLG-based reshaping, a new parameter, denoted sps_reshaper_signal_type, is added, where the value sps_reshaper_signal_type indicates the type of signal being reshaped (e.g., 0 for gamma-based SDR signal, 1 for PQ coded signal, and 2 for HLG coded signal).

[0498] Examples of syntax tables for HDR reshaping in the SPS and slice headers for both PQ and HLG are shown in Tables 20 and 21, with all the features discussed earlier (e.g., ROI, loop filter optimization (ILFOPT), and ChromaDQPAdjustment).

[0499] Table 20: Example SPS syntax for reshaping

[0500]

[0501] sps_in_loop_filter_opt_flag equal to 1 specifies that in-loop filter optimization is to be performed in the reshaped domain in the coded video sequence (CVS).

[0502] sps_in_loop_filter_opt_flag equal to 0 specifies that in-loop filter optimization is to be performed in the un-reshaped domain in the CVS. sps_luma_based_chroma_qp_offset_flag equal to 1 specifies that a luma-based chroma QP offset is derived (e.g., according to Table 11 or Table 12) and applied to the chroma coding of each CU in the coded video sequence (CVS). sps_luma_based_chroma_qp_offset_flag equal to 0 specifies that luma-based chroma QP offset is not enabled in the CVS.

[0503] Table 21: Example syntax for reshaping at slice level

[0504]

[0505] Improving chroma quality

[0506] Supporters of HLG-based encoding argue that HLG-based encoding provides better backward compatibility with SDR signaling. Thus, in theory, HLG-based signals can take the same encoding settings as traditional SDR signals. However, when viewing HLG-encoded signals in HDR mode, some color artifacts can still be observed, especially in achromatic regions (such as white and gray). In embodiments, such artifacts can be reduced by adjusting the chromaQPoffset values during encoding. It is suggested that for HLG content, a less aggressive chroma QP adjustment than used when encoding PQ signals be applied. For example, in reference

[10] , a model that assigns QP offsets for Cb and Cr based on luma QP and factors based on capture color primaries and representation color primaries is described as:

[0507] QPoffsetCb = Clip3(-12, 0, Round(c cb *(k*QP + 1))), (18a)

[0508] QPoffsetCr = Clip3(-12, 0, Round(c cr(k * QP + 1)), (18b)

[0509] where c = 1 if the capture color primaries are identical to the representation color primaries, c = 1.04 if the capture color primaries are identical to the P3 D65 primaries and the representation color primaries are identical to the Rec. ITU-R BT.2020 primaries, and c = 1.14 if the capture color primaries are identical to the Rec. ITU-R BT.709 primaries and the representation color primaries are identical to the Rec. ITU-R BT.2020 primaries. cb cb cb cr cr cr Finally, k = -0.46 and 1 = 0.26.

[0510] In embodiments, it is proposed to use the same model but with different parameters to produce less intense chromaQPOffset variations. For example, without limitation, in embodiments, for Cb in equation (18a), c = 1, k = -0.2 and 1 = 7, and for Cr in equation (18b), c = 1, k = -0.2, and 1 = 7. cb cr FIG. 6A and FIG. 6B An example of how the chromaQPOffset values vary as a function of the luminance quantization parameter (QP) for PQ (Rec. 709) and HLG is depicted. The variations of the PQ-related values are more significant than the HLG-related values. FIG. 6A Corresponding to Cb (equation (18a)), while FIG. 6B Corresponding to Cr (equation (18b)).

[0511] REFERENCES

[0512] Each of the references listed herein is incorporated by reference in its entirety.

[0513] ​​​​​​​[1] PCT Application PCT / US2016 / 025082, In-Loop Block-Based Image Reshaping in High Dynamic Range Video Coding, filed March 30, 2016, also published as WO 2016 / 164235 by G-M. Su, for Content Adaptive Reshaping.

[0514] [2] D. Baylon, Z. Gu, A. Luthra, K. Minoo, P. Yin, F. Pu, T. Lu, T. Chen, W. Husak, Y. He, L. Kerofsky, Y. Ye, B. Yi, Response to Call for Evidence for HDR and WCG Video Coding: Arris, Dolby and InterDigital, Doc. m36264, July 2015, Warsaw, Poland.

[0515] [3] U.S. Patent Application 15 / 410,563, Content-Adaptive Reshaping for High Codeword representation Images, filed January 19, 2017 by T. Lu et al.

[0516] [4] PCT Application PCT / US2016 / 042229, Signal Reshaping and Coding for HDR and Wide Color Gamut Signals, filed July 14, 2016, also published as WO 2017 / 011636 by P. Yin et al.

[0517] [5] K. Minoo et al., Exploratory Test Model for HDR extension of HEVC, MPEG Output Document, JCTVC-W0092 (m37732), 2016, San Diego, USA.

[0518] [6] E. Francois, J. Sole, J. P. Yin, "Common Test Conditions for HDR / WCG video coding experiments," JCTVC document Z1020, Geneva, Jan. 2017.

[0519] [7] A. Segall, E. Francois, and D. Rusanovskyy, "JVET common test conditions and evaluation procedures for HDR / WCG Video," JVET-E1020, ITU-T Meeting, Geneva, Jan. 2017.

[0520] [8] JEM 6.0 software: https: / / jvet.hhi.fraunhofer.de / svn / svn HM JEM Software / tags / HM-16.6- JEM-6.0

[0521] [9] T. Lu, et al., "Adaptive Chroma Quantization in Video Coding for Multiple Color Imaging Formats," U.S. Provisional Patent Application Serial No. 62 / 406,483, filed October 11, 2016, also filed as U.S. Patent Application Serial No. 15 / 728,939, published as U.S. Patent Application Publication US 2018 / 0103253.

[0522]

[10] J. Samuelsson, et al. (editors), "Conversion and coding practices for HDR / WCG Y'CbCr 4:2:0 Video with PQ Transfer Characteristics," JCTVC-Y1017, ITU-T / ISO Meeting, Chengdu, Oct. 2016.

[0523]

[11] ITU-T H.265, "High efficiency video coding," ITU, 4.0 edition, (12 / 2016).

[0524] Example computer system implementations

[0525] Embodiments of the invention can be implemented with a computer system, a system configured with electronic circuitry and components, an integrated circuit (IC) device such as a microcontroller, a field-programmable gate array (FPGA), or other configurable or programmable logic device (PLD), a discrete time or digital signal processor (DSP), an application-specific IC (ASIC), and / or one or more of such systems, devices, or components in combination with the other systems, devices, or components. The computer and / or IC can execute, control, or perform instructions related to integrated signal shaping and image encoding, such as those described herein. The computer and / or IC can compute any of the various parameters or values related to the signal shaping and encoding processes described herein. Image and video embodiments can be implemented in hardware, software, firmware, and various combinations thereof.

[0526] Certain embodiments of the invention include a computer processor executing software instructions that cause the processor to perform the methods of the invention. For example, one or more processors in a display, encoder, set-top box, transcoder, etc. can implement the methods related to integrated signal shaping and image encoding as described above by executing software instructions in program memory accessible to the processor. The invention can also be provided in the form of a program product. The program product can include any non-transitory medium which carries a set of computer-readable signals comprising instructions which, when executed by a data processor, cause the data processor to execute a method of the invention. Program products according to the invention can take any of a variety of forms. The program product can comprise, for example, physical media such as magnetic data storage media including floppy diskettes, hard disk drives, optical data storage media including CD ROMs, DVDs, electronic data storage media including ROMs, flash RAM, or the like. The computer-readable signals on the program product can optionally be compressed or encrypted.

[0527] Where a component (e.g. a software module, processor, assembly, device, circuit, etc.) is referred to above, unless otherwise indicated, reference thereto is to be interpreted as including as equivalents both: as a component of like kind that is functionally equivalent in performing the function of the component (e.g., functionally equivalent); and as an equivalent component that is not structurally equivalent to the disclosed structure performing the function in the illustrated example embodiments of the invention.

[0528] Equivalents, Expansions, Alternatives, and Others

[0529] Example embodiments related to efficient integrated signal shaping and image encoding have been described. In the foregoing specification, embodiments of the application have been described with reference to a number of specific details that can vary depending on implementation. The specification is, therefore, to be regarded as illustrative rather than restrictive. It will be apparent to those skilled in the art that various modifications and changes can be made without departing from the scope of the application as described in the claims.

Claims

1. A method for encoding an image using a processor, the method comprising: The processor accesses the input image represented by the first codeword; A shaping architecture is selected from two or more candidate coding architectures for compressing the input image using a second codeword representation, wherein the second codeword representation allows for more efficient compression than the first codeword representation, wherein the two or more candidate coding architectures include an out-of-loop shaping architecture, an in-loop shaping architecture for intra-frame only, and an in-loop architecture for predicting residuals; and The input image is compressed according to the selected shaping architecture.

2. The method as described in claim 1, wherein, Compressing the input image according to the extra-loop shaping architecture includes: Generate a forward shaping function that maps the pixels of the input image to the second codeword representation. An inverse shaping function is generated based on the forward shaping function, wherein the inverse shaping function maps pixels from the second codeword representation to the first codeword representation; Generate a shaped input image based on the input image and the forward shaping function; and The shaped input image is compressed to generate an output bitstream.

3. The method as described in claim 1, wherein, Compressing the input image using an in-loop shaping architecture used only within frames includes: Generate a forward shaping function that maps the pixels of the input image to the second codeword representation. An inverse shaping function is generated based on the forward shaping function, wherein the inverse shaping function maps pixels from the second codeword representation to the first codeword representation; For the input pixel region in the input image that needs to be encoded in intra-frame mode; A shaped region is generated based on the input pixel region and the forward shaping function; The predicted region is calculated based on pixel data in the previously encoded spatial neighborhood. The encoded residual region is generated based on the residual between the shaped input pixel region and the predicted region; Generate decoded residual regions based on encoded regions; The reconstructed pixel region is generated based on the decoded residual region, the predicted region, and the inverse shaping function; and A reference pixel region to be stored on the reference frame buffer is generated based on the reconstructed pixel region.

4. The method of claim 1, wherein, Compressing the input image according to the in-loop architecture used for predicting the residual includes: Generate a forward shaping function that maps the pixels of the input image to a second codeword representation, wherein the second codeword representation allows for more efficient compression than the first codeword representation; An inverse shaping function is generated based on the forward shaping function, wherein the inverse shaping function maps pixels from the second codeword representation to the first codeword representation; For the input pixel region in the input image; The prediction region is calculated based on pixel data in the reference frame buffer or in the previously encoded spatial neighborhood. The shaped residual region is generated based on the input pixel region, the predicted region, and the forward shaping function; A quantized residual region is generated based on the shaped residual region; The dequantized residual region is generated based on the encoded residual region; The reconstructed pixel region is generated based on the dequantized residual region, the predicted region, the forward shaping function, and the inverse shaping function; and A reference pixel region to be stored on the reference frame buffer is generated based on the reconstructed pixel region.

5. The method of claim 1, wherein, The two or more candidate coding architectures include a hybrid in-loop architecture, wherein intra-frame slices in the input image are encoded according to an in-loop shaping architecture used only for intra-frames, and inter-frame slices in the input image are encoded according to the in-loop architecture used for predicting residuals.

6. The method of any one of claims 2 to 4, further comprising a method for optimizing encoding-related decisions based on the forward shaping function, wherein, The coding-related decisions include one or more of the following: inter-frame / intra-frame mode decision, dQP optimization, rate-distortion optimization, cross-component linear model prediction, residual prediction, adaptive clipping or loop filtering.

7. A method for decoding an encoded bitstream using a processor to generate an output image represented by a first codeword, the method comprising: Receive a coded bitstream comprising one or more coded images, wherein at least a portion of the coded images is represented using a second codeword, wherein the second codeword representation allows for more efficient compression than the first codeword representation; The shaping decoder architecture is determined based on the metadata in the encoded bitstream, wherein the shaping decoder architecture includes one of an out-of-loop shaping architecture, an in-loop shaping architecture used only for intra-frames, or an in-loop architecture used for predicting residuals. Receive the shaping information of the encoded image in the encoded bitstream; and The encoded image is decompressed according to the shaping decoder architecture to generate the output image.

8. The method of claim 7, wherein, Decompressing the encoded image according to the out-of-ring shaping architecture includes: An inverse shaping function is generated based on the shaping information, wherein the inverse shaping function maps pixels from the second codeword representation to the first codeword representation; Decompress the encoded image to generate a decoded and shaped image; and The inverse shaping function is applied to the decoded and shaped image to generate the output image.

9. The method of claim 7, wherein, Decompressing the encoded image according to an in-ring shaping architecture used only within frames includes: An inverse shaping function is generated based on the shaping information, wherein the inverse shaping function maps pixels from the second codeword representation to the first codeword representation; For regions of intra-coded images; Intra-frame prediction is used to generate the decoded region; The inversely shaped region is generated based on the inverse shaping function and the decoded region; The output pixel region of the output image is generated based on the inversely shaped region; and The output pixel region is stored in the reference pixel buffer.

10. The method of claim 7, wherein, Decompressing the encoded image according to the in-loop architecture used for predicting the residual includes: Based on the shaping information, a forward shaping function is generated that maps pixels from the first codeword representation to the second codeword representation; An inverse shaping function is generated based on the shaping information, wherein the inverse shaping function maps pixels from the second codeword representation to the first codeword representation; For the region of the encoded image; Generate the decoded and shaped residual region; The prediction region is generated based on pixels in the reference pixel buffer or in the previously decoded spatial neighborhood. The reconstructed pixel region is generated based on the decoded and shaped residual region, the predicted region, the forward shaping function, and the inverse shaping function; The output pixel region of the output image is generated based on the reconstructed pixel region; and The output pixel region is stored in the reference pixel buffer.

11. The method of claim 7, wherein, The shaping decoder architecture includes a hybrid in-loop architecture, wherein intra-frame slices in the encoded bitstream are decoded according to an in-loop shaping architecture used only for intra-frames, and inter-frame slices in the encoded bitstream are decoded according to the in-loop architecture used for predicting residuals.

12. The method of claim 7, wherein, The shaping information used for the encoded image includes one or more of the following: A flag indicating whether shaping is enabled in the encoded image. Indicators of whether plastic surgery is adaptive or predetermined. A flag indicating the shaping architecture to be used when decoding the encoded image. A flag indicating the model type used to represent either the inverse or forward integer function, or The set of syntax elements representing either the inverse integer function or the forward integer function.

13. The method of claim 12, wherein, The shaping information used for the encoded image includes one or more of the following: A flag indicating whether shaping is enabled only in the region of interest within the encoded image; as well as A flag indicating whether in-loop filtering is performed in the shaped domain, the original domain, or the inverse shaped domain.

14. An apparatus for image shaping, comprising: One or more processors, and A memory having software instructions stored thereon, which, when executed by the one or more processors, cause the method as described in any one of claims 1 to 13 to be performed.

15. A non-transitory computer-readable storage medium having computer-executable instructions stored thereon, which, when executed by one or more processors, cause to perform the method according to any one of claims 1 to 13.

Images