Hacker News Reader

Comment by jug | Hacker News Reader

Their claims about Jpegli seem to make WebP obsolete regarding lossy encoding? Similar compression estimates as WebP versus JPEG are brought up.

Hell, I question if AVIF is even worth it with Jpegli.

It's obviously "better" (higher compression) but wait! It's 1) a crappy, limited image format for anything but basic use with obvious video keyframe roots and 2) terribly slow to encode AND 3) decode due to not having any streaming decoders. To decode, you first need to download the entire AVIF to even begin decoding it, which makes it worse than even JPEG/MozJPEG in many cases despite their larger sizes. Yes, this has been benchmarked.

JPEG XL would've still been worth it though because it's just covering so much more ground than JPEG/Jpegli and it has a streaming decoder like a sensible format geared for Internet use, as well as progressive decoding support for mobile networks.

But without that one? Why not just stick with JPEG's then.

View on HN

> Their claims about Jpegli seem to make WebP obsolete regarding lossy encoding? Similar compression estimates as WebP versus JPEG are brought up.

I believe Jpegli beats WebP for medium to high quality compression. I would guess that more than half of all WebP images on the net would definitely be smaller as Jpegli-encoded JPEGs of similar quality. And note that Jpegli is actually worse than MozJPEG and libjpeg-turbo at medium-low qualities. Something like libjpeg-turbo q75 is the crossover point I believe.

> Hell, I question if AVIF is even worth it with Jpegli.

According to another test [1], for large (like 10+ Mpix) photographs compressed with high quality, Jpegli wins over AVIF. But AVIF seems to win for "web size" images. Though, as for point 2 in your next paragraph, Jpegli is indeed much faster than AVIF.

> JPEG XL would've still been worth it though because it's just covering so much more ground than JPEG/Jpegli and it has a streaming decoder like a sensible format geared for Internet use, as well as progressive decoding support for mobile networks.

Indeed. At a minimum, JXL gives you another 20% size reduction just from the better entropy coding.

[1] https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

> I would guess that more than half of all WebP images on the net would definitely be smaller as Jpegli-encoded JPEGs of similar quality.

That was what I expected a long time ago but it turns out to be a false assumption. According to Google with data from Chrome. 80%+ of images on the web are bpp 1.0+.

> And note that Jpegli is actually worse than MozJPEG and libjpeg-turbo at medium-low qualities. Something like libjpeg-turbo q75 is the crossover point I believe.

May I ask how you came to this conclusion?

The Cloudinary article appears to show jpegli beating mozjpeg and turbojpeg even at the "Medium" setting (less bits per pixel).

MozJPEG not being more precise than Jpegli at mid or lower qualities also matches with our experiments, both internal uncontrolled experiments and the rater study we published.

There was an earlier version which was not very good at medium or low quality, but Zoltan fixed that about six months ago.

Sharing similar view. I even go as far as to say jpegli ( and the potential with XYB ICC ) makes JPEG XL just not quite good enough to be worth the effort.

The good thing is that the author of XL ( Jyrki's ) claims there are potential of 20-30% bitrate savings at the low end. So I hope JPEG XL encoder continues to improve.

It's not just about the compression ratio. JPEG XL improvements in generational loss are reason enough that it should be the default format for the web.

You can always use JPEG XL lossless JPEG1 recompression to get some savings in the high end quality, too — if you trust the quality decision heuristics in jpegli/guetzli/other jpeg encoder more than the JPEG XL encoder itself.

We also provide a ~7000 lines-of-code libjxl-tiny that is more similar to jpeg encoders in complexity and coding approach, and a great starting point for building a hardware encoder.

>JPEG XL lossless JPEG1 recompression

This reminded of something. I so wish iOS 18 could support JPEG XL out of the box rather than Safari only. I have 80GB of Photos on my iPhone. Vast Majority of them were sent over by WhatsApp ( JPEG ). If iOS could simply recompress those into JPEG XL I would instantly gain ~10GB+ of storage.

What happens if you recompress them losslessly manually to JPEG XL?

The Photos app supports JPEG XL as far as I’ve been able to tell.

Yes, I agree and I think there is a hurdle in mucking with file formats alone because it always affects interoperability somewhere in the end. I think this also needs to be accounted for - the advantages need to outweigh this downside because it is a downside. I still kind of want JPEG XL but I'm starting to question how much of it is simply due to me being a geek that want tech as good as possible rather than a pragmatic view on this, and I didn't question this as much before Jpegli.

It can be a question when your uncle's/daughter's/etc phone is full of photos and they asks for advice on how to make more space.

It can be a question of if the photo fits as an email attachment etc.

'Zillions' of seconds of aggregate latency waiting time is spent each day on waiting for web sites to load. Back-of-the-envelope calculations can suggest that the value of reducing waiting time can be in hundreds of billions over the whole time of the deployment. Bandwidth cost to users and energy use may also be significant factors.

Reply on news.ycombinator.com