vpp-colorspace BUG? [QSV/NV]
Closed this issue · 3 comments
Hello rigaya
Using colorspace conversion (from bt709 to bt2020)
--vpp-colorspace matrix=bt709:bt2020nc,colorprim=bt709:bt2020,transfer=bt709:bt2020-10
VPP cspconv(p010 -> yv12(16bit))
colorspace: cspconv(yv12(16bit) -> yuv444(16bit))
matrix:bt709->GBR
transfer:bt709->linear
prim:bt709->bt2020
transfer:linear->bt2020-10
matrix:GBR->bt2020nc
cspconv(yuv444(16bit) -> p010)
Output is much darker.
Shouldn't the matrix conversion be linear?
bt709->linear->bt2020nc
instead of bt709->GBR->bt2020nc
Second thing is conversion using LUT3D
--vpp-colorspace lut3d="C:\K_TONE Vintage_KODACHROME.cube",lut3d_interp=tetrahedral
VPP cspconv(p010 -> yv12(16bit))
colorspace: cspconv(yv12(16bit) -> yuv444(16bit))
matrix:bt709->GBR
lut3d: table=C:\K_TONE Vintage_KODACHROME.cube
size=33, interp=tetrahedral
matrix:GBR->bt709
cspconv(yuv444(16bit) -> p010)
There is always a matrix conversion.
Thanks for your time,
Ragards
bt709->GBR->bt2020nc
is correct. To apply transfer and prim conversion, RGB colorformat (GBR) is required instead of YUV format (yuv444), so first conversion to GBR is applied,
There is always a matrix conversion, as lut is applied to RGB colorformat (GBR), not YUV colorformat (yuv444).
bt709->GBR->bt2020nc
is correct. To apply transfer and prim conversion, RGB colorformat (GBR) is required instead of YUV >format (yuv444), so first conversion to GBR is applied,
So the conversion is correct and the output will always be darker?
There is always a matrix conversion, as lut is applied to RGB colorformat (GBR), not YUV colorformat (yuv444).
What if the input is 10-bit bt2020, not 8-bit bt709, will it not affect the colorimetry?
So the conversion is correct and the output will always be darker?
Yes, the conversion is correct. QSVEnc does not have sdr2hdr tonemapping, so it is not possible to convert to sdr from hdr, so the output will be darker.
lut requires RGB anyway, so conversion is always required. I don't know the case of 10-bit bt2020.