Hacker News
points by MadameMinty 12 hours ago | 0 comments
Yes, it's very disheartening. We're approaching two decades of WebP, after all. At this point it's not even worth implementing its support because JXL is superior in every use case.
[–] Dwedit 12 hours ago
Not really, lossless WEBP still decodes much faster than lossless JXL, so if you need to decode the images faster, you use WEBP. Yes, you could also speculatively decode the JXL images to hide the decode time.

For lossy, neither is in a good place, since lossy AVIF beats both lossy JXL and lossy WEBP. Lossless AVIF is a joke and barely competes with PNG.

[–] MadameMinty 11 hours ago
JXL decoding can still be optimized and had significantly less time for it, so let's not be so sure if that statement holds. Last update brought much improvement at just the area you mention.

And AVIF compression ratio beats JXL only conditionally. E.g. my photo library had AVIF at 29% and JXL at 25% the input size at the same perceptual quality (SSIM2=83). Sometimes it's on par. Sometimes AVIF wins. JXL wins almost always. Not to mention you can losslessly, reversibly transcode lossy JPG files to JXL, getting significant size reduction for free.

[–] cubefox 11 hours ago
I think the case for JPEG XL is not that it's the best at everything, but that it is both quite good overall while also supporting basically every obscure image format feature under the sun. It's the potential USB of image formats.
[–] ChadNauseam 4 hours ago
> while also supporting basically every obscure image format feature under the sun

Except for gain maps :)

I don't really mind because I don't use them anyway. I prefer to use the client's tonemapper. But they are a useful feature that's not supported by (chrome's implementation of) jxl

[–] Joel_Mckay 6 hours ago
Try this, as it should support animated webp features in eom. =3

sudo apt install eom webp-pixbuf-loader libimlib2-dev libwebp-dev pkg-config libwebp-dev libgdk-pixbuf2.0-dev libgtk-3-dev