You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The above is a first, quick implementation of YCgCo-Re (matrix_coefficients=16). It is probably still incomplete, but works for the example image. A better implementation is still future work.
The -RE indicate that "even" (2) bits were added to intended bit depth, so 10-2=8 is desired RGB depth for the output.
Yes, correct. My problem is that the color-conversion function where I added it, must have the same output bpp as the input. And the whole conversion pipeline does not expect that it is desired to have less bits in the output than in the input. This needs more work. But at least, we get a usable picture now.
Activity
implement RGB to YCgCo (Y/C equal bit depths) #1572
novomesk commentedon Dec 24, 2025
I have AVIF with matrix_coefficients=16
http://188.121.162.14/zoo.avif
heif-dec gives following output:
output of avifdec:
add (incomplete) implementation of YCgCo-R color transformation (#1572)
farindk commentedon Dec 26, 2025
The above is a first, quick implementation of YCgCo-Re (
matrix_coefficients=16). It is probably still incomplete, but works for the example image. A better implementation is still future work.farindk commentedon Dec 26, 2025
Note: the example image's
pixibox says that the image has 10 bits per pixel:This is the internal YCgCo-Re space. The desired output RGB depth is 8 bits per pixel. How can we communicate this cleanly through the API?
limit color conversion function 14 bpp (#1572)
novomesk commentedon Dec 26, 2025
I understand it this way:
The -RE indicate that "even" (2) bits were added to intended bit depth,
so 10-2=8 is desired RGB depth for the output.
farindk commentedon Dec 26, 2025
Yes, correct. My problem is that the color-conversion function where I added it, must have the same output bpp as the input. And the whole conversion pipeline does not expect that it is desired to have less bits in the output than in the input. This needs more work. But at least, we get a usable picture now.