4 ms·

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...
- bick_nyers 5y ago
  Interesting, although it will depend on how bandwidth constrained your users are vs. their CPU/memory profile. If downloading images takes longer than decoding, it swings in favor of progressive decode. In .jxl, it is an optional feature.
- jonsneyers 5y ago
  Progressive JPEG has ~10 scans by default in libjpeg/mozjpeg. Lossy JPEG XL always allows minimal progression (2 scans, 1:8 followed by 1:1), and uses maybe 3-5 scans when encoding with more progression. In any case, I think the "costs too much cpu" argument is not really fair, since there is nothing forcing an implementation to do explicit flush/repaint at every scan. In fact, browsers will only do a refresh when cpu is _not_ the bottleneck, but network is. When cpu _is_ the bottleneck (e.g. the file is loaded from local cache), you can just decode the whole file non-progressively and have only a single refresh (just like with inherently non-progressive formats). If network is the bottleneck, then the choice is between cpu time (avoiding progressive previews to save some cpu effort) and human time (show previews so something can be shown earlier). I think human time is more valuable, by a few orders of magnitude.

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...

bick_nyers 5y ago
Interesting, although it will depend on how bandwidth constrained your users are vs. their CPU/memory profile. If downloading images takes longer than decoding, it swings in favor of progressive decode. In .jxl, it is an optional feature.
jonsneyers 5y ago
Progressive JPEG has ~10 scans by default in libjpeg/mozjpeg. Lossy JPEG XL always allows minimal progression (2 scans, 1:8 followed by 1:1), and uses maybe 3-5 scans when encoding with more progression. In any case, I think the "costs too much cpu" argument is not really fair, since there is nothing forcing an implementation to do explicit flush/repaint at every scan. In fact, browsers will only do a refresh when cpu is _not_ the bottleneck, but network is. When cpu _is_ the bottleneck (e.g. the file is loaded from local cache), you can just decode the whole file non-progressively and have only a single refresh (just like with inherently non-progressive formats). If network is the bottleneck, then the choice is between cpu time (avoiding progressive previews to save some cpu effort) and human time (show previews so something can be shown earlier). I think human time is more valuable, by a few orders of magnitude.