Mismatch in chroma mode coding description in text compared to software

[adarsh]

The description of chroma intra mode derivation in the text is different from the VTM software. The text needs to be updated.

[bbross]

Thanks Adarsh, could you be a little bit more specific about what is exactly the difference and what changes are required in the spec to fix it?

[adarsh]

The chroma intra mode coding in the software goes as follows:

• flag for DM_Mode
• index to symbol list for LM/non-LM modes (just two for now in the list: LM and non-LM)
• if non-LM, index to non-LM mode.

The Spec. text just specifies one symbol and uses the table to determine the mode.

[bbross]

Dear Adarsh, the VTM code is unnecessary complicated so thats why its not easy to understand and match with the sepc.

The spec does not specify just one symbol but a complete binarization (see Table 9-7):
Value of intra_chroma_pred_mode | Bin string
5 0
4 10
0 1100
1 1101
2 1110
3 1111

The first bin specifies mode 5, i.e. the DM (==0), in VTM:

    if( m_BinDecoder.decodeBin( Ctx::IPredMode[1]( 1 ) ) == 0 )
    {
      pu.intraDir[1] = DM_CHROMA_IDX;
      return;
    }

If no DM (==1), the second bin specifies mode 4, i.e. LM (==0), in VTM:

  if( pu.cs->sps->getSpsNext().getUseLMChroma() )
  {
    if( intra_chroma_lmc_mode( pu ) )
    {
      return;
    }
  }

Historically, the function CABACReader::intra_chroma_lmc_mode in VTM appears to do much more (and probably is also capable to do so) but with the adopted CCLM, its just one bit that is needed to indicate LM mode.
That is correctly described in the spec.

Last but not least, if no LM (==1), the third and the fourth bin specified intra chroma modes 0,1,2,3. in VTM:

unsigned candId = m_BinDecoder.decodeBinsEP( 2 );

Hence I would close it as invalid until convinced that there is indeed a mismatch.