Opened 4 years ago
Closed 4 years ago
#1153 closed defect (fixed)
Semantics of sps_scaling_matrix_for_alternative_colour_space_disabled_flag
Reported by: | vdrugeon | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | spec | Version: | |
Keywords: | Cc: | ksuehring, bbross, XiangLi, fbossen, jvet@… |
Description
At first sight, the semantics of sps_scaling_matrix_for_alternative_colour_space_disabled_flag equal to 0 seems not to be the opposite of the semantics for value 1. For the value 1 the scaling matrix is disabled for blocks with a colour space NOT EQUAL to the designated colour space of the scaling matrix, but for the value 0 the scaling matrix is applied for blocks with a colour space EQUAL to the designated colour space of the scaling matrix, which sounds the same as for value 1. Based on the usage of sps_scaling_matrix_for_alternative_colour_space_disabled_flag in 8.7.3 (Scaling process for transform coefficients), I suspect that the semantics for value 0 should probably be: "sps_scaling_matrix_for_alternative_colour_space_disabled_flag equal to 0 specifies that for the CLVS scaling matrices are enabled and may be applied to the blocks when the colour space of the blocks is NOT equal to the designated colour space of scaling matrices." Please check!
In addition, the following inference has a typo in the flag's name: sps_scaling_matrix_for_alternative_colour_sapce_disabled_flag (sapce instead of space)
Change history (2)
comment:1 Changed 4 years ago by siwamura
comment:2 Changed 4 years ago by bbross
- Resolution set to fixed
- Status changed from new to closed
Will be fixed in JVET-S2001-vA.
Thank you for pointing this out.
I agree with you.
We need to add "NOT" for the case that the sps flag is equal to 0.
Also, typo should be fixed as mentioned.