Opened 13 days ago

#572 new defect

Incorrect use of chroma distortion weights if Cb and Cr QP offsets differ (affects perceptual QPA, may affect SBT in HDR-PQ CTCs)

Reported by: crhelmrich Owned by:
Priority: major Milestone: VTM-6.2
Component: VTM Version: VTM-6.1
Keywords: Cc: ksuehring, XiangLi, fbossen, jvet@…

Description

VTM 6.x, in initEncSlice(), calls setUpLambda() to initialize the Cb and Cr distortion weights. These weights are computed, and multiplied onto the respective component distortions in RdCost::getDistPart(), independently for Cb and Cr. However, there are some places where an average chroma weight is calculated via RdCost::getChromaWeight() and used for both Cb and Cr. This does not seem to be an issue with the SDR or HDR-HLG CTCs, but if I understand correctly, different Cb and Cr QP offsets (and, thus, different Cb and Cr lambdas) may occur in the HDR-PQ CTCs.

Therefore, in the case of unequal Cb and Cr QP offsets, the following encoder functions may, according to my understanding, work suboptimally:

  • rate control (if pCfg->getUseRateCtrl() in encodeCtus(), not sure if this is used)
  • perceptual QPA with chroma QP adaptation (e.g., if pCfg->getUsePerceptQPA() && pcSlice->getPPS()->getUseDQP() in encodeCtus())
  • SBT fast algorithm (InterSearch::calcMinDistSbt() called in xEncodeInterResidual()).

Before I submit a merge request with a proposed fix (used of a RdCost::getDistortionWeight(compID) instead of the RdCost::getChromaWeight() at the respective places), it would be great if someone could confirm that my understanding is correct.

Thanks and best,

Christian

Change history (0)

Note: See TracTickets for help on using tickets.