4 ms·

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

by NavinF 5y ago

elevaet 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago
[deleted]
prvc 5y ago
You can experiment with https://squoosh.app/ https://squoosh.app/ , although I am unsure how up-to-date its encoders are.

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

by NavinF 5y ago

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

elevaet 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago

[deleted]

prvc 5y ago

You can experiment with https://squoosh.app/ https://squoosh.app/ , although I am unsure how up-to-date its encoders are.