JPEG XL and the Pareto Front

Re:JPEG XL and the Pareto Front by edflsafoiewq on Friday March 01, 2024 @08:35AM (#39561602)

IIRC the way you encode grayscale in WebP is a SUBTRACT_GREEN transform that makes the red and blue channel 0 everywhere, and then use a 1-element prefix code for R and B, so the R and B for each pixel take zero bits. Same idea with A for opaque images. Do you know why that's not good enough?

[ Parent | on HN ]

Re:JPEG XL and the Pareto Front by JyrkiAlakuijala on Friday March 01, 2024 @08:52AM (#39561750)

I made a mistake there with subtract green.

If I had just added 128 to the residuals, all remaining prediction arithmetic would have worked better and it would have given 1 % more density.

This is because most related arithmetic for predicting pixels is done in unsigned 8 bit arithmetic. Subtract green moves such predictions to often cross the 0 -> 255 boundary, and then averaging, deltas etc make little sense and add to the entropy.

[ Parent | on HN ]

Re:JPEG XL and the Pareto Front by edflsafoiewq on Friday March 01, 2024 @08:54AM (#39561772)

Can you explain why?

[ Parent | on HN ]

Re:JPEG XL and the Pareto Front by JyrkiAlakuijala on Friday March 01, 2024 @08:58AM (#39561805)

I edited the answer into the previous message for better flow.

[ Parent | on HN ]

Re:JPEG XL and the Pareto Front by a-french-anon on Friday March 01, 2024 @09:59AM (#39562366)

Thankfully the following comment explains more than I know, I was speaking purely from empiric experience.

[ Parent | on HN ]

Re:JPEG XL and the Pareto Front by edflsafoiewq on Friday March 01, 2024 @10:05AM (#39562415)

Then you can't know that any difference you see is because of how WebP encodes grayscale.

[ Parent | on HN ]