5 ms·

The WASM is only 311kb, so for an image heavy site this can easily be offset by the savings on image sizes. It seems quite quick too, are there any benchmarks?

The WASM is only 311kb, so for an image heavy site this can easily be offset by the savings on image sizes. It seems quite quick too, are there any benchmarks? There isn't any source in the repository for the WASM, thats slightly worrying as it's difficult to confirm the Apache License realy applies. I assume you are using an existing JPEG XL decoding lib? (Edit - Source here: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/...) Are you doing any progressive decoding while it downloads? I believe that is one of the features of JPEG XL. Anyone wanting a good overview of JPEG XL, there is a good one here: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... Aside: This is a great example of how awesome Mutation Observers are, they are the foundation of so many nice new "minimal" front end tools like HTMX and Alpine.js.

samwillis 4y ago
To answer my own question, they have extracted the decoder from this Google Chrome Labs "Sploosh" project [0], all the sources are here: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... It's under an Apache license, and so the correct license applies. 0: https://squoosh.app https://squoosh.app
- haolez 4y ago
  I don't know why, but the design of Squoosh's page is very appealing to me. Must be some design witchcraft :)
- cxr 4y ago
  > all the sources are here: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... Did you check? There aren't really any sources there, either. From having already spent some time looking into this to track down what, exactly, you should patch should you want to make modifications, it looks like it's using the decoder from the JPEG XL reference implementation, libjxl (which is available under a BSD license): <https://github.com/libjxl/libjxl https://github.com/libjxl/libjxl>
lucideer 4y ago
> this can easily be offset by the savings on image sizes Maybe but I wouldn't say "easily". Only if you're considering bandwidth in isolation as your only bottleneck & neglecting client-side processing. The combination of it being WASM & being run in a Web Worker should mitigate that a lot but it's still going to be a non-zero cost, particularly in terms of RAM usage for any reasonably "large" image perf. problem being solved. On top of that the 311kb download & execution/io processing, while small, is an up front blocking perf cost whereas loading images directly will at least be parallelised entirely (small images especially rendering immediately, before the WASM would've even downloaded). It's a really cool project that'd definitely improve perf. for many cases. I'd just be reluctant to say "easily offset". The other extra factor here is the overhead of abstraction/maintenance/likely developer mistakes due to the added code complexity of your new client-side decoding pipeline.
- deleted 4y ago
  [deleted]
- rektide 4y ago
  Such a pity that host-origin isolation has fucked over the would be ways to make this good. We could have a couple CDN modules that can get loaded/forked in (something wasm is increasingly good at), or even shoved into an invisible processor iframe, but because we are freaked out about privacy (rightly), everyones gonna re-load & re-instantiate the necessary modules independently. I always thought the vision of the web as cooperating participating pieces of code was so awesome, was going to lead to vast vast efficiency savings. Tons of modules would just be available, be ambiently running. We've spent so long making modules on the web maybe perhaps possible. But just before prime time, we cancel every since ounce of win & savings by imposing huge host-origin isolation domains, all to avoid letting a host know a user had some code already. Because that indeed could be tracked. I both get it, it makes sense, but my god, what a last minute rug pull on such a huge long saga of the industry & my own maturation.
BiteCode_dev 4y ago
Maybe on desktop, but on mobile I don't think the benefit would be that clear cut, because mobile are slow, and heavy computations drain battery pretty fast.
Jyaif 4y ago
> The WASM is only 311kb That's gargantuan.
- samwillis 4y ago
  Not if you have 10mb of images on the page... at that point it makes a significant saving.
  - yakubin 4y ago
    Which is 1-2 full-sized photos from a 30Mpx camera. More if it’s just thumbnails.
  - Jyaif 4y ago
    Yes it will save bandwidth in many cases, it doesn't change the fact that for an image decoder 300KB is huge.
    - lifthrasiir 4y ago
      If you are going to leverage vectorization for performance (and WebAssembly does support 128-bit vector instructions), it's very much inevitable for binary size to increase.
- pizza 4y ago
  I'd agree with that if it were about a JPEG decoder - JPEG is a simple algorithm. But JPEG XL is really quite complex. Like kinda really complex. It is better described as a mixing pot for lots of different, individually-impressive contributions to image compression accumulated over years of open source iteration, rather than a succinctly describable algorithm. like it would be better to call it a hybrid of the existing flif/fuif/lode png/pik/brunsli/guetzli/gritibanzli/butteraugli/gralic projects, and it's also using libhwy for cross-platform simd. 311 kb, to run that via js, is amazing, imo.
JyrkiAlakuijala 4y ago
libjxl project members have currently a 174 kB wasm decoder Making it reflect only libjxl-tiny functionality should make it 25-50 kB if my guesswork is correct (libjxl-tiny is about 10x smaller than full blown libjxl).

samwillis 4y ago

To answer my own question, they have extracted the decoder from this Google Chrome Labs "Sploosh" project [0], all the sources are here: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... It's under an Apache license, and so the correct license applies. 0: https://squoosh.app https://squoosh.app

haolez 4y ago
I don't know why, but the design of Squoosh's page is very appealing to me. Must be some design witchcraft :)
cxr 4y ago
> all the sources are here: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... Did you check? There aren't really any sources there, either. From having already spent some time looking into this to track down what, exactly, you should patch should you want to make modifications, it looks like it's using the decoder from the JPEG XL reference implementation, libjxl (which is available under a BSD license): <https://github.com/libjxl/libjxl https://github.com/libjxl/libjxl>

lucideer 4y ago

> this can easily be offset by the savings on image sizes Maybe but I wouldn't say "easily". Only if you're considering bandwidth in isolation as your only bottleneck & neglecting client-side processing. The combination of it being WASM & being run in a Web Worker should mitigate that a lot but it's still going to be a non-zero cost, particularly in terms of RAM usage for any reasonably "large" image perf. problem being solved. On top of that the 311kb download & execution/io processing, while small, is an up front blocking perf cost whereas loading images directly will at least be parallelised entirely (small images especially rendering immediately, before the WASM would've even downloaded). It's a really cool project that'd definitely improve perf. for many cases. I'd just be reluctant to say "easily offset". The other extra factor here is the overhead of abstraction/maintenance/likely developer mistakes due to the added code complexity of your new client-side decoding pipeline.

deleted 4y ago
[deleted]
rektide 4y ago
Such a pity that host-origin isolation has fucked over the would be ways to make this good. We could have a couple CDN modules that can get loaded/forked in (something wasm is increasingly good at), or even shoved into an invisible processor iframe, but because we are freaked out about privacy (rightly), everyones gonna re-load & re-instantiate the necessary modules independently. I always thought the vision of the web as cooperating participating pieces of code was so awesome, was going to lead to vast vast efficiency savings. Tons of modules would just be available, be ambiently running. We've spent so long making modules on the web maybe perhaps possible. But just before prime time, we cancel every since ounce of win & savings by imposing huge host-origin isolation domains, all to avoid letting a host know a user had some code already. Because that indeed could be tracked. I both get it, it makes sense, but my god, what a last minute rug pull on such a huge long saga of the industry & my own maturation.

BiteCode_dev 4y ago

Maybe on desktop, but on mobile I don't think the benefit would be that clear cut, because mobile are slow, and heavy computations drain battery pretty fast.

Jyaif 4y ago

> The WASM is only 311kb That's gargantuan.

samwillis 4y ago
Not if you have 10mb of images on the page... at that point it makes a significant saving.
- yakubin 4y ago
  Which is 1-2 full-sized photos from a 30Mpx camera. More if it’s just thumbnails.
- Jyaif 4y ago
  Yes it will save bandwidth in many cases, it doesn't change the fact that for an image decoder 300KB is huge.
  - lifthrasiir 4y ago
    If you are going to leverage vectorization for performance (and WebAssembly does support 128-bit vector instructions), it's very much inevitable for binary size to increase.
pizza 4y ago
I'd agree with that if it were about a JPEG decoder - JPEG is a simple algorithm. But JPEG XL is really quite complex. Like kinda really complex. It is better described as a mixing pot for lots of different, individually-impressive contributions to image compression accumulated over years of open source iteration, rather than a succinctly describable algorithm. like it would be better to call it a hybrid of the existing flif/fuif/lode png/pik/brunsli/guetzli/gritibanzli/butteraugli/gralic projects, and it's also using libhwy for cross-platform simd. 311 kb, to run that via js, is amazing, imo.

JyrkiAlakuijala 4y ago

libjxl project members have currently a 174 kB wasm decoder Making it reflect only libjxl-tiny functionality should make it 25-50 kB if my guesswork is correct (libjxl-tiny is about 10x smaller than full blown libjxl).