4 ms·

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

by jug 3y ago

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.

lonjil 3y ago
> 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 https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
- ksec 3y ago
  > 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+.
  - deleted 3y ago
    [deleted]
- miragecraft 3y ago
  > 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).
  - JyrkiAlakuijala 3y ago
    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.
ksec 3y 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.
- themerone 3y ago
  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.
- JyrkiAlakuijala 3y ago
  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.
  - ksec 3y ago
    >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.
    - JyrkiAlakuijala 3y ago
      What happens if you recompress them losslessly manually to JPEG XL?
    - spider-mario 3y ago
      The Photos app supports JPEG XL as far as I’ve been able to tell.

by jug 3y ago

lonjil 3y ago

> 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 https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

ksec 3y ago
> 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+.
- deleted 3y ago
  [deleted]
miragecraft 3y ago
> 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).
- JyrkiAlakuijala 3y ago
  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.

ksec 3y 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.

themerone 3y ago
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.
JyrkiAlakuijala 3y ago
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.
- ksec 3y ago
  >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.
  - JyrkiAlakuijala 3y ago
    What happens if you recompress them losslessly manually to JPEG XL?
  - spider-mario 3y ago
    The Photos app supports JPEG XL as far as I’ve been able to tell.