Opened 11 months ago
Last modified 8 months ago
#1632 new defect
Incorrect indexing used for choosing matrix intra sample prediction
Reported by: | peterderivaz | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | H.266/VVC v4 |
Component: | spec | Version: | H.266/VVC v3 |
Keywords: | Cc: | ksuehring, bbross, XiangLi, fbossen, jvet@… |
Description
Clause 8.4.5.2.1 reads:
Inputs to this process are: – a sample location ( xTbCmp, yTbCmp ) specifying the top-left sample of the current transform block relative to the top-left sample of the current picture, ... if MipChromaDirectFlag[ xTbCmp ][ yTbCmp ] is equal to 1 and cIdx is not equal to 0,
This looks up values in MipChromaDirectFlag based on counts of chroma samples.
However, when MipChromaDirectFlag is derived, the indexing is done based on counts of luma samples:
Derivation process for chroma intra prediction mode Input to this process are: – a luma location ( xCb, yCb ) specifying the top-left sample of the current chroma coding block relative to the top-left luma sample of the current picture, ... In this process, the chroma intra prediction mode IntraPredModeC[ xCb ][ yCb ] and the MIP chroma direct mode flag MipChromaDirectFlag[ xCb ][ yCb ] are derived.
I think this can be fixed by changing 8.4.5.2.1 to use "MipChromaDirectFlag[ xTbCmp * SubWidthC ][ yTbCmp * SubHeightC ]" instead of "MipChromaDirectFlag[ xTbCmp ][ yTbCmp ]".
Change history (1)
comment:1 Changed 8 months ago by bbross
- Milestone set to H.266/VVC v4
- Version set to H.266/VVC v3
Note: See TracTickets for help on using tickets.
Good catch, thanks! This was indeed an oversight and should take the chroma subsampling into account as suggested. Will be fixed in v4.