JVET-N0220 Simplification of Reshaper Implementation [T. Lu, F. Pu, P. Yin, S. McCarthy, W. Husak, T. Chen (Dolby)]
This contribution presents four normative changes to simplify VTM4 LMCS implementation:
- reduction of the pipeline delay for computing average luma for chroma residue scaling;
- reduction of the size of the local buffer needed to store chroma residue samples;
- unification of the fixed-point precision used in luma mapping and chroma residue scaling;
- unification of the method of calculating chroma residue scale with the method of calculating the luma inverse scale, and removal of the pre-computed LUT.
The combined simplification test results for SDR CTC over the VTM4.0 anchor are {BDRate for Y, U, V}:
- AI: 0.00%, 0.00%, 0.00%;
- RA: 0.01%, -0.05%, -0.01%;
- LDB: 0.01%, -0.09%, -0.42%;
- LDP: -0.01%, -0.19%, -0.07%.
The encoding and decoding times are found to be similar to VTM4.0.
This contribution also presents some non-CTC results for three non-normative topics:
- results for a VTM non-normative modification to enable support of InternalBitDepth other than 10;
- results for a test for interactions between LMCS and local QP adjustment. The test results indicate that LMCS and local QP adjustment are independent and the respective coding gains are additive. Test results for RA Class B/C/D/F are {average BDRate for Y,U,V}:
- local QP only: -0.48%, -0.91%, -0.96%;
- LMCS only: -1.48%, 2.85%, 2.85%;
- both: -1.94%, 1.76%, 1.85%;
- diff (c – (a + b)): 0.02%, -0.18%, -0.04%;
- test results for SCC TGM test sequences, (average BDRate for Y,U,V)
- AI: -1.36%, 0.00%, 0.23%;
- RA: -1.44%, -0.15%, 0.09%;
- LDB: -1.67%, -0.10%, -0.19%;
- LDP: -2.12%, -0.40%, -041%.
Aspect 1 is targeting the same issue as JVET-N0113, but is even simpler because it does not use an average but just the to left luma sample. Some experts say that this may be a questionable for certain type of content.
Study this aspect as a possible approach to the latency problem in CE.
Aspect 2 reduces the local buffer by 2.5 Kbyte by clipping right after inverse transform, i.e. the clipped values are used for scaling. This does not have any impact on performance. By the time when CS was adopted it was not clear that the local buffer size would increase. This is an obvious that should be adopted as cleanup.
Aspect 3 reduces the fixed-point precision of luma scaling from 14 to 11 bit (in total 3+11 bit, as scaling is a floating point representation), same as chroma now. Looks as a reasonable cleanup which could be adopted.
Aspect 4 proposes to replace the current expression of chroma scaling by a LUT through a computation formula doing piecewise linear mapping. This has a small deviation in results. However, if it is confrmed that the algorithm reproduces more or less the same values as the current LUT, this should be adopted as a reasonable cleanup (D. Rusanovskyy later confirmed in Tuesday morning Track A session that this is the case)
Another part of the contribution shows that LMCS would also work with other bit depth, and with local QP adjustment. There is some loss in chroma for RA, which is asserted to the fact that chroma scaling currently is disabled in case of dual tree.
LMCS and the current luma dQP of HDR CTC should not be used together, as they are not aligned with each other. Currently, LMCS shall be disabled in HDR CTC, unless there would be a proof that it povides better visual quality standalone than the luma dQP optimization.
Decision (cleanup): Adopt JVET-N0220 aspects 2, 3, and 4
After some discussion in the Sunday plenary discussion, the method of clipping was further discussed in Track A Tuesday morning. New results in v3 of the document with the “special clipping” disabled indicated that a loss of 0.25% was observed in class D and 0.15% in class B. Loss is 0.07% on average in RA.
The “special clipping” is a processing that performs clipping into a range of 16 to 235 (scaled by bitdepth) whenever the first and last segment of the piecewise linear mapping don’t have any codewords, which could indicate that the original sequence was clipped to that range (effectively, only one end would be clipped)
It is also noted that JEM had an element where it was expicitly signalled which was the lowest and highest value of a dgiven picture, and then performed clipping to that range at the output. The BD rate benefit of that method was higher, but it was not transferred to VVC, as that was asserted to be dangerous as it might have interference with other tools).
It is generally agreed that it would be cleaner to not execute that specific clipping.
Decision (cleanup): Remove the special case in the clipping stage from LMCS (see powerpoint deck in v3, page 27)