Mismatch of condition for chroma process in LMCS (8.7.5.3) compared with VTM

[ksthey]

In 8.7.5.1:
– Otherwise, if cIdx is equal to 1, tuCbfChroma is set equal to tu_cb_coded_flag[ xCurr ][ yCurr ], recSamples corresponds to the reconstructed chroma sample array SCb.
– Otherwise (cIdx is equal to 2), tuCbfChroma is set equal to tu_cr_coded_flag[ xCurr ][ yCurr ], recSamples corresponds to the reconstructed chroma sample array SCr.

8.7.5.3 is invoked in 8.7.5.1 with tuCbfChroma as one of the input to decide whether to perform residual scaling for chroma samples.

In the specifiation (JVET-S2001-vG), the values of tu_cb_coded_flag and tu_cr_coded_flag are parsed from bitstream (or equal to 0 if they are not parsed from bitstream), without any further modification regardless of the value for tu_joint_cbcr_residual_flag.

However, in VTM, the code below indicates that LMCS for chroma will be executed when tu_joint_cbcr_residual_flag (tu.jointCbCr) equals to 1, regardless of the value of TU coded flag (tu_cb_coded_flag or tu_cr_coded_flag) for current color component:

  flag = flag && (tu.blocks[compID].width*tu.blocks[compID].height > 4);
  if (flag && (TU::getCbf(tu, compID) || tu.jointCbCr) && isChroma(compID) && slice.getPicHeader()->getLmcsChromaResidualScaleFlag())
  {
    piResi.scaleSignal(tu.getChromaAdj(), 0, tu.cu->cs->slice->clpRng(compID));
  }

[crhelmrich]

Indeed, a conditioning on tu_joint_cbcr_residual_flag[][] seems to have been forgotten in 8.7.5.1. What do people think about the following?

– Otherwise, if cIdx is equal to 1, tuCbfChroma is set equal to (tu_cb_coded_flag[ xCurr ][ yCurr ] | | tu_joint_cbcr_residual_flag[ xCurr ][ yCurr ]), recSamples corresponds to the reconstructed chroma sample array SCb.
– Otherwise (cIdx is equal to 2), tuCbfChroma is set equal to (tu_cr_coded_flag[ xCurr ][ yCurr ] | | tu_joint_cbcr_residual_flag[ xCurr ][ yCurr ]), recSamples corresponds to the reconstructed chroma sample array SCr.

This uses the boolean '| |' but a binary '|' may also work (and may actually be preferable since, in 8.7.5.3, it reads, "If tuCbfChroma is equal to 1"). Not sure which is used more commonly in the text.

Christian

[crhelmrich]

Having consulted the initial authors of 8.7.5 and considered the text in 8.8.3.5, it seems the "correct correction" in 8.7.5.1 would be:

– Otherwise, if cIdx is equal to 1, tuCbfChroma is set equal to (tu_cb_coded_flag[ xCurr * SubWidthC ][ yCurr * SubHeightC ] | | tu_joint_cbcr_residual_flag[ xCurr * SubWidthC ][ yCurr * SubHeightC ]), recSamples corresponds to the reconstructed chroma sample array SCb.
– Otherwise (cIdx is equal to 2), tuCbfChroma is set equal to (tu_cr_coded_flag[ xCurr * SubWidthC ][ yCurr * SubHeightC ] | | tu_joint_cbcr_residual_flag[ xCurr * SubWidthC ][ yCurr * SubHeightC ]), recSamples corresponds to the reconstructed chroma sample array SCr.

Accordingly, in 8.7.5.3, it should read:

– tu_cb_coded_flag [ xCurr * SubWidthC ][ yCurr * SubHeightC ] is equal to 0, and tu_cr_coded_flag [ xCurr * SubWidthC ][ yCurr * SubHeightC ] is equal to 0 and cu_act_enabled_flag[ xCurr * SubWidthC ][ yCurr * SubHeightC ] is equal to 0.

I also noticed that there are only a few occurrences of "subHeightC" and "subWidthC" but more than 200 each of "SubHeightC" and "SubWidthC", so I conclude that the upper-case writing is the correct one. Which means equation (1188) in 8.7.5.1 should be corrected as well.

Christian

[jlchen]

Good catch! I think the final suggested solution is good to be. All the reported issues will be fixed in S2001-vH release.

In addition, I also did two more changes as follows:

1) "– tu_cb_coded_flag [ xCurr * SubWidthC ][ yCurr * SubHeightC ] is equal to 0, and tu_cr_coded_flag[ xCurr * SubWidthC ][ yCurr * SubHeightC ] is equal to 0 and " in subclause 8.7.5.3

2) Clarify the definition of [x0][y0] of tu_cb_coded_flag and tu_cr_coded_flag in subclause 7.4.12.10