Methods and apparatus of local illumination compensation model derivation and inheritance for video coding
By refining and strategically utilizing inherited and non-local LIC parameters in merge candidate lists, the method addresses inefficiencies in video coding under complex lighting, improving encoding and decoding performance.
Patent Information
- Application Number
- PCT/CN2025/075519
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-02-07
- Filing Date
- 2025-01-27
- Publication Date
- 2025-08-14
AI Technical Summary
Existing video coding technologies face challenges in efficiently handling local illumination variations, leading to suboptimal encoding and decoding performance, particularly in scenarios involving complex lighting conditions.
The method involves deriving and refining Local Illumination Compensation (LIC) parameters by modifying initial inherited parameters and inserting them into specialized merge candidate lists, utilizing both inherited and non-local LIC parameters to enhance encoding and decoding efficiency.
This approach improves encoding and decoding efficiency by optimizing LIC parameter usage, reducing computational overhead, and enhancing video quality under varying illumination conditions.
Smart Images

Figure CN2025075519_14082025_PF_FP_ABST
Abstract
Description
METHODS AND APPARATUS OF LOCAL ILLUMINATION COMPENSATION MODEL DERIVATION AND INHERITANCE FOR VIDEO CODINGCROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present invention is a non-Provisional Application of and claims priority to U.S. Provisional Patent Application No. 63 / 550,672, filed on February 7, 2024. The U.S. Provisional Patent Application is hereby incorporated by reference in its entirety.FIELD OF THE INVENTION
[0002] The present invention relates to video coding system. In particular, the present invention relates to local illumination compensation model derivation and inheritance in a video coding system. BACKGROUND AND RELATED ART
[0003] Versatile video coding (VVC) is the latest international video coding standard developed by the Joint Video Experts Team (JVET) of the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Moving Picture Experts Group (MPEG) . The standard has been published as an ISO standard: ISO / IEC 23090-3: 2021, Information technology -Coded representation of immersive media -Part 3: Versatile video coding, published Feb. 2021. VVC is developed based on its predecessor HEVC (High Efficiency Video Coding) by adding more coding tools to improve coding efficiency and also to handle various types of video sources including 3-dimensional (3D) video signals.
[0004] Fig. 1A illustrates an exemplary adaptive Inter / Intra video encoding system incorporating loop processing. For Intra Prediction 110, the prediction data is derived based on previously coded video data in the current picture. For Inter Prediction 112, Motion Estimation (ME) is performed at the encoder side and Motion Compensation (MC) is performed based on the result of ME to provide prediction data derived from other picture (s) and motion data. Switch 114 selects Intra Prediction 110 or Inter Prediction 112 and the selected prediction data is supplied to Adder 116 to form prediction errors, also called residues. The prediction error is then processed by Transform (T) 118 followed by Quantization (Q) 120. The transformed and quantized residues are then coded by Entropy Encoder 122 to be included in a video bitstream corresponding to the compressed video data. The bitstream associated with the transform coefficients is then packed with side information such as motion and coding modes associated with Intra prediction and Inter prediction, and other information such as parameters associated with loop filters applied to underlying image area. The side information associated with Intra Prediction 110, Inter prediction 112 and in-loop filter 130, is provided to Entropy Encoder 122 as shown in Fig. 1A. When an Inter-prediction mode is used, a reference picture or pictures have to be reconstructed at the encoder end as well. Consequently, the transformed and quantized residues are processed by Inverse Quantization (IQ) 124 and Inverse Transformation (IT) 126 to recover the residues. The residues are then added back to prediction data 136 at Reconstruction (REC) 128 to reconstruct video data. The reconstructed video data may be stored in Reference Picture Buffer 134 and used for prediction of other frames.
[0005] As shown in Fig. 1A, incoming video data undergoes a series of processing in the encoding system. The reconstructed video data from REC 128 may be subject to various impairments due to a series of processing. Accordingly, in-loop filter 130 is often applied to the reconstructed video data before the reconstructed video data are stored in the Reference Picture Buffer 134 in order to improve video quality. For example, deblocking filter (DF) , Sample Adaptive Offset (SAO) and Adaptive Loop Filter (ALF) may be used. The loop filter information may need to be incorporated in the bitstream so that a decoder can properly recover the required information. Therefore, loop filter information is also provided to Entropy Encoder 122 for incorporation into the bitstream. In Fig. 1A, Loop filter 130 is applied to the reconstructed video before the reconstructed samples are stored in the reference picture buffer 134. The system in Fig. 1A is intended to illustrate an exemplary structure of a typical video encoder. It may correspond to the High Efficiency Video Coding (HEVC) system, VP8, VP9, H. 264 or VVC.
[0006] The decoder, as shown in Fig. 1B, can use similar or portion of the same functional blocks as the encoder except for Transform 118 and Quantization 120 since the decoder only needs Inverse Quantization 124 and Inverse Transform 126. Instead of Entropy Encoder 122, the decoder uses an Entropy Decoder 140 to decode the video bitstream into quantized transform coefficients and needed coding information (e.g. ILPF information, Intra prediction information and Inter prediction information) . The Intra prediction 150 at the decoder side does not need to perform the mode search. Instead, the decoder only needs to generate Intra prediction according to Intra prediction information received from the Entropy Decoder 140. Furthermore, for Inter prediction, the decoder only needs to perform motion compensation (MC 152) according to Inter prediction information received from the Entropy Decoder 140 without the need for motion estimation.
[0007] I. RELATED ART
[0008] I. 1 Local Illumination Compensation (LIC)
[0009] LIC is an inter prediction technique to model local illumination variation between a current block and its prediction block as a function between the current block template and the reference block template. The parameters of the function can be denoted by a scale α and an offset β, which forms a linear equation, α*p [x] +β to compensate illumination changes, where p [x] is a reference sample pointed to by an MV at a location x in reference picture. When wrap-around motion compensation is enabled, the MV shall be clipped with wrap-around offset taken into consideration. Since α and β can be derived based on the current block template and the reference block template, no signalling overhead is required for them, except that an LIC flag is signalled for AMVP mode to indicate the use of LIC.
[0010] The local illumination compensation proposed in JVET-O0066 (Vadim Seregin, et al., “CE4-3.1a and CE4-3.1b: Unidirectional local illumination compensation with affine prediction” , Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 15th Meeting: Gothenburg, SE, 3–12 July 2019, Document: JVET-O0066) is used for uni-prediction inter CUs with the following modifications. ● Intra neighbour samples can be used in LIC parameter derivation; ● LIC is disabled for blocks with less than 32 luma samples; ● For both non-subblock and affine modes, LIC parameter derivation is performed based on the template block samples corresponding to the current CU, instead of partial template block samples corresponding to first top-left 16x16 unit; ● Samples of the reference block template are generated by using MC with the block MV without rounding it to integer-pel precision.
[0011] I. 2 Bi-Predictive LIC
[0012] In the method, the LIC mode is extended to bi-predictive CUs. Specifically, two different linear models are applied to the two prediction blocks which are then combined to generate the bi-prediction samples of the current CU: P′ [x, y] = (1-ω) ·p′0 [x, y] +ω·p′1 [x, y] , and p′0 [x, y] =α0·P0 [x, y] +β0, p′1 [x, y] =α1·P1 [x, y] +β1, where α0 and β0, and α1 and β1 indicate the scales and the offsets in L0 and L1, respectively; ω indicates the weight (as indicated by the CU-level BCW index) for the weighted combination of L0 and L1 predictions. The same derivation scheme of the LIC mode is reused and applied in one iterative manner to derive the L0 and L1 LIC parameters. Specifically, the method firstly derives the L0 parameters by minimizing difference between L0 template prediction T0 and the template T and the samples in T are updated by subtracting the corresponding samples in T0. Then, the L1 parameters are calculated that minimizes the difference between L1 template prediction T1 and the updated template. Finally, the L0 parameter is refined again in the same way.
[0013] Following the current LIC design, one flag is signalled for AMVP bi-predicted CUs for the indication of the LIC mode while the flag is inherited for merge related inter CUs. Additionally, the LIC is disabled when decoder-side motion vector refinement (DMVR) (including multi-pass DMVR, adaptive DMVR and affine DMVR) and bi-directional optical flow (BDOF) is applied.
[0014] I. 3 Non-local Local Illumination Compensation (LIC)
[0015] In JVET-AF0191 (Xiaoyu Xiu, et al., “Non-EE2: Enhancements on local illumination compensation” , Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 32nd Meeting, Hannover, DE, 13–20 October 2023, Document: JVET-AF0191) , one non-local illumination compensation (NLIC) scheme is proposed. With the method, instead of using the template samples, the samples of the previously coded CUs are utilized for deriving the linear model used for the motion compensation of the current block. Specifically, after the reconstruction of each inter CU (except for GPM and SbTMVP CUs) , one linear model is derived by minimizing the difference between the reconstruction and prediction samples of the block. Then, for both regular and subblock merge modes, up to 6 NLIC candidates which are obtained from spatial adjacent and non-adjacent neighbours to current CU are inserted and reordered together with the existing candidates in the merge list. The first N candidates with the smallest SADs remain in the list with one index being signalled to indicate which candidate is selected. In the contribution, N is kept the same as ECM-10.0, i.e., 10 for regular merge mode and 15 for subblock merge mode. Additionally, the same pattern used for obtaining spatial non-adjacent neighbours in regular merge is reused to locate the corresponding non-adjacent NLIC candidates. When one NLIC candidate is selected, the associated linear model is used together with its motion information (e.g., MVs, CPMVs, reference picture indices and so forth) to generate the prediction samples of the CU.
[0016] I. 4 An LIC flag for Inter Prediction Merge Modes
[0017] In JVET-AF0194 (Y. Zhang, et al., “Non-EE2: On LIC flag in merge mode” , Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 32nd Meeting, Hannover, DE, 13–20 October 2023, Document: JVET-AF0194) , it was proposed to signal an LIC flag for inter-prediction merge modes, instead of inheriting the flag value from a merge candidate. The flag is signalled to indicate if the original inherited LIC flag or the reverse LIC flag value is used for a merge candidate. The flag is signalled for regular merge mode, affine merge mode and TM (Template Matching) merge mode. Also, it is proposed to enable LIC with PU level BDMVR and BDOF.
[0018] In the present invention, methods and apparatus to derive LIC model are disclosed. BRIEF SUMMARY OF THE INVENTION
[0019] A method and apparatus for video coding using LIC coding tool are disclosed. According to the method, input data associated with a current block is received, wherein the input data comprise pixel data to be encoded at an encoder side or coded data associated with the current block to be decoded at a decoder side. Initial inherited LIC (Local Illumination Compensation) parameters are determined for the current block. The initial inherited LIC parameters is modified to generate one or more sets of refined inherited LIC parameters. At least one of one or more refined candidates associated with said one or more sets of refined inherited LIC parameters is inserted into at least one of one or more merge candidate lists. The current block is encoded or decoded by using coding information comprising said at least one of one or more refined candidates.
[0020] In one embodiment, a set of target refined inherited LIC parameters is derived by inheriting only one or more parts of the initial inherited LIC parameters and re-calculating remaining parts of the initial inherited LIC parameters. In one embodiment, said inheriting only said one or more parts of the initial inherited LIC parameters correspond to inheriting only a slope or only an offset of the initial inherited LIC parameters.
[0021] In one embodiment, the initial inherited LIC parameters include LIC parameters, non-local LIC parameters, non-local LIC parameters derived from partial samples of a CU (Coding Unit) , history-based LIC parameters, multi-model LIC parameters, multi-tap LIC parameters, or any kind of LIC parameters derived from one or more previous coded CUs (Coding Units) . In one embodiment, said one or more refined candidates are inserted into a first merge list and one or more initial inherited candidates associated with the initial inherited LIC parameters are inserted into a second merge list.
[0022] In one embodiment, said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidate lists comprise a first merge candidate list and a second merge candidate list, and wherein the first merge candidate list contains first candidates with LIC flag inheritance and the second merge candidate list contains second candidates with both the LIC flag inheritance and LIC parameters inheritance. In one embodiment, said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidate lists comprise a first merge candidate list and a second merge candidate list, and wherein the first merge candidate list contains first candidates with inherited LIC parameters and the second merge candidate list contains second candidates with non-local LIC parameters. In one embodiment, said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidate lists comprise a first merge candidate list and a second merge candidate list, and wherein a number of candidates in the first merge candidate list, the second merge candidate list, or both is constrained.
[0023] In one embodiment, said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidate lists comprise a first merge candidate list and a second merge candidate list, and wherein one or more candidates are insert into the first merge candidate list and the second merge candidate list according to TM (Template Matching) costs. In one embodiment, said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidates with same motion information, but different LIC parameters are used to calculate the TM costs respectively. In one embodiment, said one or more merge candidate lists correspond to two or more merge candidate lists and when one of said two or more merge candidates corresponds to a spatial neighbouring block, four candidates are generated if inherited LIC flag is enabled. In one embodiment, the four candidates correspond to self-derived LIC candidate, inherited LIC candidate, non-local LIC candidate, and LIC-off candidate.
[0024] According to another method, two or more merge candidate lists are determined. A merge list index for selecting one target merge list from said two or more merge candidate lists is signalled or parsed. According to the merge list index, an LIC (Local Illumination Compensation) parameter index for selecting one or more target LIC parameters is signalled or parsed. The current block is encoded or decoded by using coding information comprising the merge list index and the LIC parameter index.
[0025] In one embodiment, said two or more merge candidate lists comprise one or more regular merge candidates, one or more TM (Template Matching) merge candidates, one or more BM (Bilateral Matching) merge candidates, one or more MMVD (Merge Mode with MV Difference) merge candidates, one or more CIIP (Combined Intra / Inter Prediction) merge candidates, one or more affine merge candidates, one or more SbtMVP (Subblock-based Temporal Motion Vector Prediction) merge candidates, or any combination thereof.BRIEF DESCRIPTION OF THE DRAWINGS
[0026] Fig. 1A illustrates an exemplary adaptive Inter / Intra video coding system incorporating loop processing.
[0027] Fig. 1B illustrates a corresponding decoder for the encoder in Fig. 1A.
[0028] Fig. 2 illustrates a flowchart of an exemplary video coding system that modifies initial inherited LIC parameters to generate refined inherited LIC parameters according to an embodiment of the present invention.
[0029] Fig. 3 illustrates a flowchart of an exemplary video coding system that signals or parses a merge list index to select a target merge list from two or more merge candidate lists according to an embodiment of the present invention.DETAILED DESCRIPTION OF THE INVENTION
[0030] It will be readily understood that the components of the present invention, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the systems and methods of the present invention, as represented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. References throughout this specification to “one embodiment, ” “an embodiment, ” or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment.
[0031] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, etc. In other instances, well-known structures, or operations are not shown or described in detail to avoid obscuring aspects of the invention. The illustrated embodiments of the invention will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout. The following description is intended only by way of example, and simply illustrates certain selected embodiments of apparatus and methods that are consistent with the invention as claimed herein.
[0032] II. PROPOSED METHOD
[0033] II. 1 Two LIC Merge Lists in Merge Mode
[0034] LIC parameters of the reference block pointed by the inherited motion vector can be inherited by the current block (inherited LIC parameters) . In this case, LIC parameters of the current block do not need to be re-derived again based on current block’s templates and referenced block’s templates.
[0035] In one embodiment, two merge lists are derived in merge mode. A flag is signalled in the bitstream to indicate the final predictor is generated from which merge list.
[0036] The context variable of this flag for different merge mode can be different. For example, if the block is coded by affine mode, the first context variable will be used to code the flag. If the block is coded by non-affine mode, the second context variable will be used to code the flag.
[0037] For another example, if the block is coded by template-matching related merge mode, the first context variable will be used to code the flag. If the block is coded by non-template-matching related merge mode, the second context variable will be used to code the flag.
[0038] II. 1.1 One list contains merge candidates with inherited LIC parameters, and one list contains merge candidates with non-local LIC parameters
[0039] In one embodiment, a first merge list is generated which contains motion information and the inherited LIC parameters of spatial neighbouring blocks, non-adjacent neighbouring blocks, temporal neighbouring blocks and history-based blocks and so on. A second merge list is generated which contains motion information and its non-local LIC parameters of spatial neighbouring blocks, non-adjacent neighbouring blocks, temporal neighbouring blocks and history-based blocks and so on.
[0040] In the previously mentioned embodiment, only if the reference block’s LIC flag is enabled, can the corresponding candidate with inherited LIC parameters be referenced in the first merge list. Also, only if the reference block’s non-local LIC parameters exist, can the corresponding candidate with non-local LIC parameters be referenced in the second list.
[0041] In another embodiment, in the first merge list, only if the reference block’s LIC flag is enabled, can the corresponding inherited LIC parameters be referenced in the first merge list. Otherwise, the reference block’s motion information and its non-local LIC parameters will be inserted into the first merge list if the non-local LIC parameters of the reference block exist. Besides, the same reference blocks with the same motion information will not be inserted into the second merge list again.
[0042] II. 1.2 One list contains merge candidates with inherited LIC flags, and one list contains merge candidates with non-local LIC parameters
[0043] In one embodiment, a first merge list is generated which contains motion information and the inherited LIC flag of spatial neighbouring blocks, non-adjacent neighbouring blocks, temporal neighbouring blocks and history-based blocks and so on. If a candidate inherits an enabled LIC flag, the LIC parameters will be derived by using current block’s templates and reference block’s templates. A second merge list is generated which contains motion information and its non-local LIC parameters of spatial neighbouring blocks, non-adjacent neighbouring blocks, temporal neighbouring blocks and history-based blocks and so on.
[0044] In the previously mentioned embodiment, only if the reference block’s non-local LIC parameters exist, can the reference block be referenced in the second merge list.
[0045] In another embodiment, only if the reference block’s non-local LIC parameters exist, can the reference block be referenced in the second merge list. Otherwise, if the reference block’s LIC flag is enabled, the reference block’s motion information and the inherited LIC parameters will be inserted into the second merge list.
[0046] In another embodiment, if the reference block’s LIC flag is enabled, the reference block’s motion information and the inherited LIC parameters will be inserted into the second merge list. Otherwise, if the reference block’s non-local LIC parameters exist, the reference block’s motion information and its non-local LIC parameters will be inserted into the second merge list.
[0047] II. 1.3 One list contains merge candidates with inherited LIC flags, and one list contains merge candidates with non-local LIC parameters or inherited LIC parameters
[0048] In one embodiment, a first merge list is generated which contains motion information and the inherited LIC flag of spatial neighbouring blocks, non-adjacent neighbouring blocks, temporal neighbouring blocks and history-based blocks and so on. If a candidate inherits an enabled LIC flag, the LIC parameters will be derived by using current block’s templates and reference block’s templates. A second merge list is generated which contains motion information and its non-local LIC parameters of spatial neighbouring blocks, non-adjacent neighbouring blocks, temporal neighbouring blocks and history-based blocks and so on.
[0049] Besides, motion information and the inherited LIC parameters of spatial neighbouring blocks, non-adjacent neighbouring blocks, temporal neighbouring blocks and history-based blocks and so on are also included in the second merge list if the reference block’s LIC flag is enabled.
[0050] II. 1.4 Constraining the number of merge candidates in two merge lists
[0051] In one embodiment, two merge lists can both include candidates with inherited LIC parameters and candidates with non-local LIC parameters. The number of added candidates with inherited LIC parameters in two merge lists is constrained to be equal. Besides, the number of added candidates with non-local LIC parameters is constrained to be equal.
[0052] In one embodiment, two merge lists can both include candidates with inherited LIC parameters and candidates with non-local LIC parameters. The maximum numbers of candidates in two merge lists are constrained to be equal.
[0053] In one embodiment, two merge lists can both include candidates with inherited LIC parameters and candidates with non-local LIC parameters. The maximum numbers of added candidates with inherited LIC parameters and candidates with non-local LIC parameters in two merge lists are constrained to be equal.
[0054] In one embodiment, candidates with non-local LIC parameters can be inserted into two merge list in an interleaving manner. For example, the first candidate with non-local LIC parameters will be inserted into the first merge list, the second candidate with non-local LIC parameters will be inserted into the second merge list, the third candidate with non-local LIC parameters will be inserted into the first merge list, the fourth candidate with non-local LIC parameters will be inserted into the second merge list, and so on. Also, candidates with inherited LIC parameters can be inserted into two merge list in an interleaving manner.
[0055] In the above-mentioned embodiments, the referenced order of candidates with inherited LIC parameters and candidates with non-local LIC parameters can be pre-defined. For example, the referenced position order is from above, left, above-right, left-bottom, above-left, non-adjacent positions (from the positions closer to current block to the positions farer to current block) . The referenced position order of candidates with inherited LIC parameters and candidates with non-local LIC parameters can be the same, but not limited to.
[0056] II. 1.5 Using TM costs to determine candidates to insert into two merge lists
[0057] In one embodiment, TM costs can be considered when generating two merge lists. Candidates with same motion information, but different LIC parameters can be used to calculate TM costs respectively. For example, when a spatial neighbouring block is referenced, four candidates are generated if the inherited LIC flag is enabled. The candidate with the smallest TM cost will be inserted into the first merge list. The candidate with the second smallest TM cost will be inserted into the second merge list. Other candidates will not be inserted.
[0058] In another embodiment, when a spatial neighbouring block is referenced, four candidates are generated if the inherited LIC flag is enabled. The candidate with the smallest TM cost will be inserted into the first merge list. Other candidates will be inserted into the second merge list.
[0059] In another embodiment, when a spatial neighbouring block is referenced, four candidates are generated if the inherited LIC flag is enabled. The candidates with the first N smaller TM costs will be inserted into the first merge list. Other candidates will be inserted into the second merge list. Alternatively, other candidates will not be inserted. N can be any integer smaller than 5.
[0060] In another embodiment, when a spatial neighbouring block is referenced, four candidates are generated if the inherited LIC flag is enabled. The candidates will be inserted into two merge lists in an interleaving manner according to their TM cost. For example, the candidate with the smallest TM cost will be inserted into the first merge list. The candidate with the second smallest TM cost will be inserted into the second merge list. The candidate with the third smallest TM cost will be inserted into the first merge list. The candidate with the fourth smallest TM cost will be inserted into the second merge list.
[0061] The four candidates mentioned in the above embodiments include a candidate with non-local LIC parameters, a candidate with inherited LIC parameters, a candidate with LIC disabled, and a candidate with self-derived LIC parameters (LIC parameters are derived by using current block’s templates and reference block’s templates) .
[0062] When a spatial neighbouring block’s LIC flag is not enabled, only three candidates will be added. That is, a candidate with non-local LIC parameters, a candidate with LIC disabled, and a candidate with self-derived LIC parameters.
[0063] The spatial neighbouring block mentioned in the above examples can be changed to non-adjacent reference blocks, temporal reference blocks, or history-based reference block, or other pre-defined default reference blocks.
[0064] II. 1.6 Favouring inherited candidates during TM costs comparison
[0065] In one embodiment, TM costs can be considered when generating two merge lists. Candidates with same motion information, but different LIC parameters can be used to calculate TM costs respectively. To increase the chance of candidates with inherited LIC parameters, before comparison, the TM costs of candidates with inherited LIC parameters can be multiplied by a ratio. The ratio is a value smaller than 1.
[0066] The ratio value can be designed based on current CU size, merge mode type, or current temporal layer number, or QP value.
[0067] The ratio mentioned above can also be used for the TM costs calculated with non-local LIC candidates, with LIC flag off, or with self-derived LIC parameters.
[0068] II. 1.7 Selecting LIC parameters from an inherited LIC parameter list
[0069] In the current ECM, a specific merge candidate list is constructed for each merge mode. That is, a regular merge candidate list is constructed for regular merge mode and another TM merge candidate list is constructed for TM merge mode. However, in JVET-AF0194, two merge candidate lists are constructed for regular merge mode. One list contains the candidates with original inherited LIC flag, and another list contains the candidates with reverse LIC flag. According to the design, further extending the design is disclosed in this invention.
[0070] In one invention, a mergeList index is signalled to indicate the selection of merge candidate list for merge modes. After the mergeList index signalling, an LIC parameter index can be further signalled according to the mergeList index to indicate the selection of LIC parameter from an LIC parameter list. That is, multiple merge candidate lists are constructed for a merge mode including regular, TM, BM (Bilateral Matching) , MMVD (Merge Mode with MV Difference) , CIIP (Combined Intra / Inter Prediction) , Affine, SbtMVP (Subblock-based Temporal Motion Vector Prediction) and any other merge modes. The signalled mergeList index is used to indicate which merge list is used for a certain merge mode. Some of the merge lists contain the candidates with determined LIC parameters, but some of the merge lists contain the candidates with indeterminate LIC parameters which need to be determined by signalling. If the merge list with indeterminate LIC parameters is selected, an LIC parameter index can be further signalled to indicate the inherited LIC parameter from an inherited LIC parameter list.
[0071] In one embodiment, two merge candidate lists are constructed for each merge mode. The first list contains the candidates with original merge candidates with inherited or reverse LIC flag and k0 (k0>=0) candidates with inherited LIC parameters. The second list contains the candidates with inherited or reverse LIC flag and k1 (k1>=0) candidates with inherited LIC parameters. For one of the merge candidate lists, an LIC parameter index can be further signalled to indicate the selection of LIC parameter from the corresponding LIC parameter list.
[0072] In one embodiment, two merge candidate lists are constructed for each merge modes. The first list contains the candidates with original merge candidates with inherited or reverse LIC flag and k0 (k0>=0) candidates with inherited LIC parameters. The second list contains the candidates with inherited or reverse LIC flag and k1 (k1>=0) candidates with inherited LIC parameters. For each merge candidate list, an LIC parameter index can be further signalled to indicate the selection of LIC parameter from the corresponding LIC parameter list.
[0073] The number of the merge lists can be any number and the containing candidates can be arbitrarily designed.
[0074] II. 1.8 Merge candidate lists containing refined inherited LIC parameters
[0075] In the above-mentioned embodiments, the candidates with inherited LIC parameters are inserted into merge lists. To further increase the diversity of testing LIC parameters, some variations can be applied to initial inherited LIC parameters to derive more inherited LIC parameters when the LIC parameters of a reference block are referenced.
[0076] In one embodiment, the new inherited LIC parameters can be generated by only inheriting parts of initial inherited LIC parameters (e.g. only inheriting the slope or offset) after scaling according to the POC difference of previously coded CU and re-calculating the remaining parts of LIC parameters by using template samples.
[0077] In one embodiment, the new inherited LIC parameters can be generated by only inheriting parts of initial inherited LIC parameters (e.g. only inheriting the slope or offset) and re-calculating the remaining parts of LIC parameters by using template samples.
[0078] In one embodiment, the new inherited LIC parameters can be generated by scaling the initial inherited LIC parameters or adding offsets on the slope or offset on the initial inherited LIC parameters.
[0079] The initial inherited LIC parameters include the LIC parameters, non-local LIC parameters, non-local LIC parameters derived from partial samples of a CU, history-based LIC parameters, multi-model LIC parameters, multi-tap LIC parameters (i.e., the LIC parameter derived by CCCM method) or any kind of LIC parameters derived from previous coded CUs.
[0080] In one embodiment, candidates with new inherited LIC parameters and candidates with initial inherited LIC parameters can be inserted into the same merge list.
[0081] In one embodiment, candidates with new inherited LIC parameters are inserted into the first merge list and candidates with initial inherited LIC parameters can be inserted into the second merge list.
[0082] In one embodiment, new inherited LIC parameters and initial inherited LIC parameters can be inserted into the same LIC parameter list.
[0083] In one embodiment, either new inherited LIC parameters or initial inherited LIC parameters can be inserted into the LIC parameter list. The selection can be determined based on, but not limit to TM costs.
[0084] II. 2 One LIC Merge List in Merge Mode
[0085] In one embodiment, TM costs can be considered when generating a merge list. For example, a spatial neighbouring block is referenced with LIC flag enabled. Four candidates will be generated based on the inherited motion information and different LIC parameters. Only the first N candidate with the smallest TM cost will be inserted into the merge list. Other candidates will not be inserted. N can be the value larger than 0 and smaller than 5.
[0086] The four candidates mentioned in the above example include candidates with non-local LIC parameters, candidates with inherited LIC parameters, candidates with LIC disabled, and candidates with self-derived LIC parameters (LIC parameters are derived by using current block’s templates and reference block’s templates) .
[0087] In one embodiment, TM costs can be considered when generated a merge list. For example, a spatial neighbouring block is referenced with LIC flag disabled. Three candidates will be generated based on the inherited motion information and different LIC parameters. Only the first N candidate with the smallest TM cost will be inserted into the merge list. Other candidates will not be inserted. N can be the value larger than 0 and smaller than 4.
[0088] The three candidates mentioned in the above example includes candidate with non-local LIC parameters, candidate with LIC disabled, and candidate with self-derived LIC parameters (LIC parameters are derived by using current block’s templates and reference block’s templates) .
[0089] To increase the chance of candidates with inherited LIC parameters to be inserted, before comparison, the TM costs of candidates with inherited LIC parameters can be multiplied by a ratio. The ratio is a value smaller than 1.
[0090] The ratio value can be designed based on the current CU size, merge mode type, or current temporal layer number, or QP value.
[0091] The ratio mentioned above can also be added to the TM costs calculated with non-local LIC candidates, with LIC flag off, or with self-derived LIC parameters.
[0092] The foregoing proposed methods can be implemented in encoders and / or decoders. For example, the proposed method can be implemented in an in-loop filtering module of an encoder, and / or an in-loop filtering module of a decoder.
[0093] Any of the foregoing proposed methods of chained LIC flag derivation or LIC parameter adjustment can be applied independently or jointly. Moreover, any of the foregoing proposed methods can be implemented in encoders and / or decoders. For example, any of the proposed methods can be implemented in inter prediction module of an encoder and / or a decoder. Alternatively, any of the proposed methods can be implemented as a circuit coupled to inter prediction module of the encoder and / or the decoder. With reference to the encoder and decoder in Fig. 1A and Fig. 1B, any of the proposed candidate derivation method can be implemented in an Inter coding module (e.g. MC 152 in Fig. 1B) in a decoder or an Inter coding module (e.g. Inter Pred. 112 in Fig. 1A) in an encoder. Any of the proposed methods can also be implemented as a circuit coupled to the intra / inter coding module at the decoder or the encoder. However, the decoder or encoder may also use additional processing unit to implement the proposed methods. While the Inter Pred. units (e.g. unit 112 in Fig. 1A and unit 152 in Fig. 1B) are shown as individual processing units, they may correspond to executable software or firmware codes stored on a media, such as hard disk or flash memory, for a CPU (Central Processing Unit) or programmable devices (e.g. DSP (Digital Signal Processor) or FPGA (Field Programmable Gate Array) ) .
[0094] Fig. 2 illustrates a flowchart of an exemplary video coding system that modifies initial inherited LIC parameters to generate refined inherited LIC parameters according to an embodiment of the present invention. The steps shown in the flowchart may be implemented as program codes executable on one or more processors (e.g., one or more CPUs) at the encoder side. The steps shown in the flowchart may also be implemented based hardware such as one or more electronic devices or processors arranged to perform the steps in the flowchart. According to the method, input data associated with a current block is received in step 210, wherein the input data comprise pixel data to be encoded at an encoder side or coded data associated with the current block to be decoded at a decoder side. Initial inherited LIC (Local Illumination Compensation) parameters is determined for the current block in step 220. The initial inherited LIC parameters is modified to generate one or more sets of refined inherited LIC parameters in step 230. At least one of one or more refined candidates associated with said one or more sets of refined inherited LIC parameters is inserted into at least one of one or more merge candidate lists in step 240. The current block is encoded or decoded by using coding information comprising said at least one of one or more refined candidates in step 250.
[0095] Fig. 3 illustrates a flowchart of an exemplary video coding system that signals or parses a merge list index to select a target merge list from two or more merge candidate lists according to an embodiment of the present invention. According to the method, input data associated with a current block is received in step 310, wherein the input data comprise pixel data to be encoded at an encoder side or coded data associated with the current block to be decoded at a decoder side. Two or more merge candidate lists are determined in step 320. A merge list index for selecting one target merge list from said two or more merge candidate lists is signalled or parsed in step 330. According to the merge list index, an LIC (Local Illumination Compensation) parameter index for selecting one or more target LIC parameters is signalled or parsed in step 340. The current block is encoded or decoded by using coding information comprising the merge list index and the LIC parameter index in step 350.
[0096] The flowchart shown is intended to illustrate an example of video coding according to the present invention. A person skilled in the art may modify each step, re-arranges the steps, split a step, or combine steps to practice the present invention without departing from the spirit of the present invention. In the disclosure, specific syntax and semantics have been used to illustrate examples to implement embodiments of the present invention. A skilled person may practice the present invention by substituting the syntax and semantics with equivalent syntax and semantics without departing from the spirit of the present invention.
[0097] The above description is presented to enable a person of ordinary skill in the art to practice the present invention as provided in the context of a particular application and its requirement. Various modifications to the described embodiments will be apparent to those with skill in the art, and the general principles defined herein may be applied to other embodiments. Therefore, the present invention is not intended to be limited to the particular embodiments shown and described, but is to be accorded the widest scope consistent with the principles and novel features herein disclosed. In the above detailed description, various specific details are illustrated in order to provide a thorough understanding of the present invention. Nevertheless, it will be understood by those skilled in the art that the present invention may be practiced.
[0098] Embodiment of the present invention as described above may be implemented in various hardware, software codes, or a combination of both. For example, an embodiment of the present invention can be one or more circuit circuits integrated into a video compression chip or program code integrated into video compression software to perform the processing described herein. An embodiment of the present invention may also be program code to be executed on a Digital Signal Processor (DSP) to perform the processing described herein. The invention may also involve a number of functions to be performed by a computer processor, a digital signal processor, a microprocessor, or field programmable gate array (FPGA) . These processors can be configured to perform particular tasks according to the invention, by executing machine-readable software code or firmware code that defines the particular methods embodied by the invention. The software code or firmware code may be developed in different programming languages and different formats or styles. The software code may also be compiled for different target platforms. However, different code formats, styles and languages of software codes and other means of configuring code to perform the tasks in accordance with the invention will not depart from the spirit and scope of the invention.
[0099] The invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described examples are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Claims
1.A method of video coding, the method comprising:receiving input data associated with a current block, wherein the input data comprise pixel data to be encoded at an encoder side or coded data associated with the current block to be decoded at a decoder side;determining initial inherited LIC (Local Illumination Compensation) parameters for the current block;modifying the initial inherited LIC parameters to generate one or more sets of refined inherited LIC parameters;inserting at least one of one or more refined candidates associated with said one or more sets of refined inherited LIC parameters into at least one of one or more merge candidate lists; andencoding or decoding the current block by using coding information comprising said at least one of one or more refined candidates.2.The method of Claim 1, wherein a set of target refined inherited LIC parameters is derived by inheriting only one or more parts of the initial inherited LIC parameters and re-calculating remaining parts of the initial inherited LIC parameters.3.The method of Claim 2, wherein said inheriting only said one or more parts of the initial inherited LIC parameters correspond to inheriting only a slope or only an offset of the initial inherited LIC parameters.4.The method of Claim 1, wherein the initial inherited LIC parameters include self-derived LIC parameters, non-local LIC parameters, non-local LIC parameters derived from partial samples of a CU (Coding Unit) , history-based LIC parameters, multi-model LIC parameters, multi-tap LIC parameters, or any kind of LIC parameters derived from one or more previous coded CUs (Coding Units) .5.The method of Claim 1, wherein said one or more refined candidates associated with the refined LIC parameters are inserted into a first merge list and one or more initial inherited candidates associated with the initial inherited LIC parameters are inserted into a second merge list.6.The method of Claim 1, wherein said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidate lists comprise a first merge candidate list and a second merge candidate list, and wherein the first merge candidate list contains first candidates with LIC flag inheritance and the second merge candidate list contains second candidates with both the LIC flag inheritance and LIC parameters inheritance.7.The method of Claim 1, wherein said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidate lists comprise a first merge candidate list and a second merge candidate list, and wherein the first merge candidate list contains first candidates with inherited LIC parameters and the second merge candidate list contains second candidates with non-local LIC parameters.8.The method of Claim 1, wherein said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidate lists comprise a first merge candidate list and a second merge candidate list, and wherein a number of candidates in the first merge candidate list, the second merge candidate list, or both is constrained.9.The method of Claim 1, wherein said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidate lists comprise a first merge candidate list and a second merge candidate list, and wherein one or more candidates are insert into the first merge candidate list and the second merge candidate list according to TM (Template Matching) costs.10.The method of Claim 9, wherein said one or more merge candidate lists correspond to two or more merge candidate lists and said two or more merge candidates with same motion information, but different LIC parameters are used to calculate the TM costs respectively.11.The method of Claim 10, wherein said one or more merge candidate lists correspond to two or more merge candidate lists and when one of said two or more merge candidates corresponds to a spatial neighbouring block, four candidates are generated if inherited LIC flag is enabled.12.The method of Claim 11, wherein the four candidates correspond to self-derived LIC candidate, inherited LIC candidate, non-local LIC candidate, and LIC-off candidate.13.An apparatus for video coding, the apparatus comprising one or more electronic circuits or processors arranged to:receive input data associated with a current block, wherein the input data comprise pixel data to be encoded at an encoder side or coded data associated with the current block to be decoded at a decoder side;determine initial inherited LIC (Local Illumination Compensation) parameters for the current block;modify the initial inherited LIC parameters to generate one or more sets of refined inherited LIC parameters;insert at least one of one or more refined candidates associated with said one or more sets of refined inherited LIC parameters into at least one of one or more merge candidate lists; andencode or decode the current block by using coding information comprising said at least one of one or more refined candidates.14.A method of video coding, the method comprising:receiving input data associated with a current block, wherein the input data comprise pixel data to be encoded at an encoder side or coded data associated with the current block to be decoded at a decoder side;determining two or more merge candidate lists;signalling or parsing a merge list index for selecting one target merge list from said two or more merge candidate lists;according to the merge list index, signalling or parsing an LIC (Local Illumination Compensation) parameter index for selecting one or more target LIC parameters; andencoding or decoding the current block by using coding information comprising the merge list index and the LIC parameter index.15.The method of Claim 14, wherein said two or more merge candidate lists comprise one or more regular merge candidates, one or more TM (Template Matching) merge candidates, one or more BM (Bilateral Matching) merge candidates, one or more MMVD (Merge Mode with MV Difference) merge candidates, one or more CIIP (Combined Intra / Inter Prediction) merge candidates, one or more affine merge candidates, one or more SbTMVP (Subblock-based Temporal Motion Vector Prediction) merge candidates, or any combination thereof.16.An apparatus for video coding, the apparatus comprising one or more electronic circuits or processors arranged to:receive input data associated with a current block, wherein the input data comprise pixel data to be encoded at an encoder side or coded data associated with the current block to be decoded at a decoder side;determine two or more merge candidate lists;signal or parse a merge list index for selecting one target merge list from said two or more merge candidate lists;according to the merge list index, signal or parse an LIC (Local Illumination Compensation) parameter index for selecting one or more target LIC parameters; andencode or decode the current block by using coding information comprising the merge list index and the LIC parameter index.
Citation Information
Patent Citations
Video processing using local illumination compensation
CN112913247A
Low latency local illumination compensation
US20200099941A1
Method, apparatus, and medium for video processing
WO2024011126A1