Hacker News

points by MadameMinty 11 hours ago | 0 comments

Worth pointing out that PNG is also just awful and should probably die like BMP died. WebP was already available at the time this article was written:

PNG: 1039993 bytes - baseline

optimized*: 541539

WebP: 398974 - lossless mode, of course.

JPEG XL: 310778 - lossless, quick, and easy.

*after monumental compute effort; still probably some room for improvement but the effort is ridiculous.

[–] ashleyn 11 hours ago

WebP stands on its own merits but it's profoundly annoying that as of Pop OS 22.04 I still have to open them up in Firefox instead of Eye of Gnome. Compatibility issues like this are littered everywhere. This laziness on the part of supporting WebP is a significant driver of continued use of PNG.

[–] SchemaLoad 4 hours ago

Open a bug report on Eye of Gnome. WebP has no issues opening on all of the native MacOS tooling. Since this is an open source program it should be fairly easy to submit a PR to bring in webP support.

[–] MadameMinty 11 hours ago

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 11 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 9 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 10 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 3 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 5 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

[–] F3nd0 11 hours ago

With JPEG XL finally being allowed into mainstream web browsers, we’ll hopefully see more native platform support and be able to slowly phase every older codec out, since JPEG XL does very well at more or less everything (except for animation, compared to video codecs).

[–] MadameMinty 10 hours ago

I hope so, but I disagree with the size of the "except": JXL performs better than APNG and GIF, and still supports transparency and lossless encode. Video codecs struggle here. So even with animation it still depends!

There's also a case for AVIF in some use cases (for this image it performs poorly). But if I had to choose one, I'd choose JXL.

[–] MadameMinty 11 hours ago

For completeness, my background job of the highest imaginable PNG compression yielded optimized: 528313 bytes. Took only several minutes...