So... why are we still having problems with banding in image compression? If anything, gradients should be the easiest things to compress in these images, because the compression algorithms work entirely in the frequency domain. Whatever is introducing banding here is adding more frequency coefficients and making the image bigger and worse at the same time.
Did Google/On2 just not notice that they were crushing every gradient they encode or is are all the common WebP encoders doing some kind of preprocessing pass that crushes gradients and munges luma?
I would guess the problem is that on a slow gradient, each individual block is very close to a constant. The tiny AC coefficients tend to be quantized away, resulting in a visible transition along block boundaries.
I thought the loop filter was supposed to help with this though.
Webp is encoded using limited ycbcr values as opposed to jpeg which uses full range ycbcr values. When converting jpeg to webp, there will be banding. Grayscale limited ycbcr when converted to full rgb during display ill also have banding.
Webp really doesnt have a banding issue unless you convert jpeg or display purely grayscale content.
Did Google/On2 just not notice that they were crushing every gradient they encode or is are all the common WebP encoders doing some kind of preprocessing pass that crushes gradients and munges luma?