4 ms·

Sounds like this particular piece of news is underwhelming, but from my own casual experimentation, JPEG XL delivers much better quality vs compression ratio th

Sounds like this particular piece of news is underwhelming, but from my own casual experimentation, JPEG XL delivers much better quality vs compression ratio than Google's WebP (and the lossless compression is really good too). I look forward to the day when JPEG XL is widely supported by web browsers. https://caniuse.com/jpegxl https://caniuse.com/jpegxl

NavinF 4y ago
You should compare it to AVIF (already supported on chrome and firefox). WebP is much older and already supported everywhere.
- elevaet 4y ago
  Thanks, I didn't know AVIF was well supported alreadyA I remember I couldn't decide if I liked AVIF or JPEG XL better quality-wise, but the support would make AVIF the clear winner.
  - theandrewbailey 4y ago
    I've been using AVIF on my blog for about a year. It's worth noting that AVIF seems to have better quality at lower sizes (~0.5 bits per pixel, ~120KB at 1080p) than JPEG XL (at least for right now), so even if browsers supported JPEG XL, you still might get better optimization with AVIF.
    - JyrkiAlakuijala 4y ago
      On the average AVIFs are 1.5 BPP and JPEGs about 2.2 BPP in the internet. If you average at 0.5 BPP, you will differentiate by having blurrier images than competing blogs.
      - theandrewbailey 4y ago
        A few reasons: 1. The vast majority of images on my blog are game screenshots. Often, a good portion of them are solid colors/gradients[0] or have blurry textures[1], which helps. When I played around with AVIF, 0.6 bpp was enough to keep the prominent parts, then tried less. For photos, unless it's a picture of grass, gravel, or trees[2], the same holds[3]. 2. I encode only high resolution (x2) images as AVIFs, so blurriness gets covered up by downscaling or high PPI screens almost all of the time. On a desktop 1080p screen, you're looking at up to 2 bpp effectively. 3. I keep individual image sizes below 160KB (0.61 bpp@1080p) to keep page load sizes at 1MB or less. Of course, I keep an archive of everything in PNG/RAW/etc format to redo if needed. Blog link: https://theandrewbailey.com/ https://theandrewbailey.com/ [0] https://theandrewbailey.com/fileImmutable/AXW_xuoI/post/2018_ShadowrunDragonfallCombat%C3%972.avif https://theandrewbailey.com/fileImmutable/AXW_xuoI/post/2018... [1] https://theandrewbailey.com/fileImmutable/AX3-7eYX/post/2021_GTA3%C3%972.avif https://theandrewbailey.com/fileImmutable/AX3-7eYX/post/2021... [2] https://theandrewbailey.com/coroner/404 https://theandrewbailey.com/coroner/404 [3] https://theandrewbailey.com/fileImmutable/AXW_xuox/post/2020_Chicken%C3%972.avif https://theandrewbailey.com/fileImmutable/AXW_xuox/post/2020...
- bick_nyers 4y ago
  The coolest part about JXL that I want to use specifically (over AVIF) is progressive coding: https://youtu.be/UphN1_7nP8U https://youtu.be/UphN1_7nP8U
  - elevaet 4y ago
    Very cool. Which reminds me, what the heck happened to old-school progressive JPEGs? I remember seeing them a lot in the early days of images on the internet, but it seems like you don't see them around anymore. Why is that?
    - theandrewbailey 4y ago
      They're still being used. A newer, optimized JPEG encoder, mozJPEG[0], seems to use progressive encoding by default. I suspect with faster internet speeds, most JPEGs download and decode so fast that the cool 'enhance' animation is rarely seen anymore. [0] https://github.com/mozilla/mozjpeg https://github.com/mozilla/mozjpeg
    - bick_nyers 4y ago
      For it to be worth the effort to implement/maintain your users need to be bandwidth-constrained, which is not really a reality anymore, jpegs don't take upwards of a minute to load for most people. It has applications still, such as in medical imaging.
    - jonsneyers 4y ago
      If you treat progressive jpeg and sequential jpeg as separate image formats, then progressive jpeg is currently the fastest growing image format on the web. If you look at the statistics, the opposite is true of what your feeling is. One thing that did change is that often the network is fast enough to make it unnecessary to show progressive passes, or if they're still shown, it happens quickly enough to be not really noticeable.
  - maxloh 4y ago
    > This is likely to put too much pressure on the CPU and memory of the decoding client as each refresh event involves a full pass through the decompression system. > On average, decoding a progressive JPEG image is equivalent to decoding the baseline one 3 times. This feature wasn't added for a reason[0]. [0]: https://developers.google.com/speed/webp/faq#does_webp_support_progressive_or_interlaced_display https://developers.google.com/speed/webp/faq#does_webp_suppo...
- deleted 4y ago
  [deleted]
- prvc 4y ago
  You can experiment with https://squoosh.app/ https://squoosh.app/ , although I am unsure how up-to-date its encoders are.
rndgermandude 4y ago
Another feature that is very interesting to me is bit-exact lossless conversation between jpeg and jpeg-xl, in both directions that is. This essentially allows to take a jpeg, run the vastly improved lossless compression stages of jpeg-xl over the the original lossy compressed jpeg data (jpeg "coefficients"), preserve metadata, and get a jpeg-xl result that the jpeg-xl implementations understand, and which you can losslessly convert back to an ordinary jpeg that is a bit-exact reproduction of the original jpeg, if need be. The compression ratio will not be as good as full jpeg-xl (having skipped the lossy stages), but you still get something in the range of 20% smaller file sizes without any additional quality loss whatsoever. This is something WEBP/AVIF/HEIC does not offer. When using those codecs, you will either have to accept additional lossy compression artifacts on top of the artifacts of the original jpeg codec, or convert in lossless mode with worse compression ratio.
- LinAGKar 4y ago
  I wonder how the compression ratio of JXL-ified JPEG compares to WEBP/AVIF/HEIC.
  - rndgermandude 4y ago
    Comparing compression ratios is tricky. What you usually want is "file size at same visual quality" or "visual quality as same file size" for comparisons. The problem here is that "visual quality" is in the eye of the beholder, Different base images will have different results. There are some attempts at such comparisons, e.g. https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... (cloudinary might be biased, as they are a major driver behind jpeg-xl) My overall impression is that it's roughly on par or a little behind with AVIF, somewhat ahead of HEIC and very ahead of WEBP (and jpeg of course) in quality-per-byte. As for encode and decode speed, it's a bit slower than WEBP but beats AVIF and HEIC by a margin (unless these codecs are back by hardware encoders). However, all three codecs are relatively new and there may be a lot of future speed optimizations possible. Especially jpeg-xl, which isn't "backed" by general AV1 (AVIF), vpx (WEBP) or HEVC (HEIC) research, may have a particularly large yet to be tapped potential for (hardware-specific) optimizations. As far as I know, jpeg-xl is also "simpler" than those other codecs (which basically used the iframes of their complex sibling video codecs as a base), so it might be more feasible to have more competing implementations. But time will tell, and it will of course also largely depend on the adoption and thus network effects of these formats who much "love" each format receives from open source and proprietary software vendors.

NavinF 4y ago

You should compare it to AVIF (already supported on chrome and firefox). WebP is much older and already supported everywhere.

elevaet 4y ago
Thanks, I didn't know AVIF was well supported alreadyA I remember I couldn't decide if I liked AVIF or JPEG XL better quality-wise, but the support would make AVIF the clear winner.
- theandrewbailey 4y ago
  I've been using AVIF on my blog for about a year. It's worth noting that AVIF seems to have better quality at lower sizes (~0.5 bits per pixel, ~120KB at 1080p) than JPEG XL (at least for right now), so even if browsers supported JPEG XL, you still might get better optimization with AVIF.
  - JyrkiAlakuijala 4y ago
    On the average AVIFs are 1.5 BPP and JPEGs about 2.2 BPP in the internet. If you average at 0.5 BPP, you will differentiate by having blurrier images than competing blogs.
    - theandrewbailey 4y ago
      A few reasons: 1. The vast majority of images on my blog are game screenshots. Often, a good portion of them are solid colors/gradients[0] or have blurry textures[1], which helps. When I played around with AVIF, 0.6 bpp was enough to keep the prominent parts, then tried less. For photos, unless it's a picture of grass, gravel, or trees[2], the same holds[3]. 2. I encode only high resolution (x2) images as AVIFs, so blurriness gets covered up by downscaling or high PPI screens almost all of the time. On a desktop 1080p screen, you're looking at up to 2 bpp effectively. 3. I keep individual image sizes below 160KB (0.61 bpp@1080p) to keep page load sizes at 1MB or less. Of course, I keep an archive of everything in PNG/RAW/etc format to redo if needed. Blog link: https://theandrewbailey.com/ https://theandrewbailey.com/ [0] https://theandrewbailey.com/fileImmutable/AXW_xuoI/post/2018_ShadowrunDragonfallCombat%C3%972.avif https://theandrewbailey.com/fileImmutable/AXW_xuoI/post/2018... [1] https://theandrewbailey.com/fileImmutable/AX3-7eYX/post/2021_GTA3%C3%972.avif https://theandrewbailey.com/fileImmutable/AX3-7eYX/post/2021... [2] https://theandrewbailey.com/coroner/404 https://theandrewbailey.com/coroner/404 [3] https://theandrewbailey.com/fileImmutable/AXW_xuox/post/2020_Chicken%C3%972.avif https://theandrewbailey.com/fileImmutable/AXW_xuox/post/2020...
bick_nyers 4y ago
The coolest part about JXL that I want to use specifically (over AVIF) is progressive coding: https://youtu.be/UphN1_7nP8U https://youtu.be/UphN1_7nP8U
- elevaet 4y ago
  Very cool. Which reminds me, what the heck happened to old-school progressive JPEGs? I remember seeing them a lot in the early days of images on the internet, but it seems like you don't see them around anymore. Why is that?
  - theandrewbailey 4y ago
    They're still being used. A newer, optimized JPEG encoder, mozJPEG[0], seems to use progressive encoding by default. I suspect with faster internet speeds, most JPEGs download and decode so fast that the cool 'enhance' animation is rarely seen anymore. [0] https://github.com/mozilla/mozjpeg https://github.com/mozilla/mozjpeg
  - bick_nyers 4y ago
    For it to be worth the effort to implement/maintain your users need to be bandwidth-constrained, which is not really a reality anymore, jpegs don't take upwards of a minute to load for most people. It has applications still, such as in medical imaging.
  - jonsneyers 4y ago
    If you treat progressive jpeg and sequential jpeg as separate image formats, then progressive jpeg is currently the fastest growing image format on the web. If you look at the statistics, the opposite is true of what your feeling is. One thing that did change is that often the network is fast enough to make it unnecessary to show progressive passes, or if they're still shown, it happens quickly enough to be not really noticeable.
- maxloh 4y ago
  > This is likely to put too much pressure on the CPU and memory of the decoding client as each refresh event involves a full pass through the decompression system. > On average, decoding a progressive JPEG image is equivalent to decoding the baseline one 3 times. This feature wasn't added for a reason[0]. [0]: https://developers.google.com/speed/webp/faq#does_webp_support_progressive_or_interlaced_display https://developers.google.com/speed/webp/faq#does_webp_suppo...
deleted 4y ago
[deleted]
prvc 4y ago
You can experiment with https://squoosh.app/ https://squoosh.app/ , although I am unsure how up-to-date its encoders are.

rndgermandude 4y ago

Another feature that is very interesting to me is bit-exact lossless conversation between jpeg and jpeg-xl, in both directions that is. This essentially allows to take a jpeg, run the vastly improved lossless compression stages of jpeg-xl over the the original lossy compressed jpeg data (jpeg "coefficients"), preserve metadata, and get a jpeg-xl result that the jpeg-xl implementations understand, and which you can losslessly convert back to an ordinary jpeg that is a bit-exact reproduction of the original jpeg, if need be. The compression ratio will not be as good as full jpeg-xl (having skipped the lossy stages), but you still get something in the range of 20% smaller file sizes without any additional quality loss whatsoever. This is something WEBP/AVIF/HEIC does not offer. When using those codecs, you will either have to accept additional lossy compression artifacts on top of the artifacts of the original jpeg codec, or convert in lossless mode with worse compression ratio.

LinAGKar 4y ago
I wonder how the compression ratio of JXL-ified JPEG compares to WEBP/AVIF/HEIC.
- rndgermandude 4y ago
  Comparing compression ratios is tricky. What you usually want is "file size at same visual quality" or "visual quality as same file size" for comparisons. The problem here is that "visual quality" is in the eye of the beholder, Different base images will have different results. There are some attempts at such comparisons, e.g. https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... (cloudinary might be biased, as they are a major driver behind jpeg-xl) My overall impression is that it's roughly on par or a little behind with AVIF, somewhat ahead of HEIC and very ahead of WEBP (and jpeg of course) in quality-per-byte. As for encode and decode speed, it's a bit slower than WEBP but beats AVIF and HEIC by a margin (unless these codecs are back by hardware encoders). However, all three codecs are relatively new and there may be a lot of future speed optimizations possible. Especially jpeg-xl, which isn't "backed" by general AV1 (AVIF), vpx (WEBP) or HEVC (HEIC) research, may have a particularly large yet to be tapped potential for (hardware-specific) optimizations. As far as I know, jpeg-xl is also "simpler" than those other codecs (which basically used the iframes of their complex sibling video codecs as a base), so it might be more feasible to have more competing implementations. But time will tell, and it will of course also largely depend on the adoption and thus network effects of these formats who much "love" each format receives from open source and proprietary software vendors.