3 ms·
Possibly an underrated but potentially very useful unique feature of JXL is that it completely eliminates the need to use a third party thumbnail/image-scaling
by pmarreck 3y ago
Possibly an underrated but potentially very useful unique feature of JXL is that it completely eliminates the need to use a third party thumbnail/image-scaling rendering site or workflow. If you need a full size JXL image rendered down to 25% size for one of your web views, you literally just truncate the bitstream at 1/4 the total (or whatever percentage of the total number of pixels of the full-size image you need, that's a trivial math calculation) and send just that.
That's tremendously simpler, both from an architectural and maintenance standpoint (for any site that deals with images), than what you would usually have to do, such as relying on either a third party host (and added cost, latency (without caching), and potential downtime/outage) or pushing it through the (very terrible and memory/cpu-wasteful codebase at this point) ImageMagick/GraphicsMagick library (and potentially managing that conversion as a background job which incurs additional maintenance overhead), or getting VIPS to actually successfully build in your CI/CD workflow (an issue I struggled with in the past while trying to get away from "ImageTragick").
You get to chuck ALL of that and simply hold onto the originals in your choice of stateful store (S3, DB, etc.), possibly caching it locally to the webserver, and just... compute the number of pixels you need given the requested dimensions (which is basically just: ((requested x)*(requested y))/((full-size x)*(full-size y)) percentage of the total binary size, capping at 100%), and bam, truncate.
Having built out multiple image-scaling (and caching, and sometimes third-party-hosted) workflows at this point, this is a very attractive feature, speaking as a developer.
- adzm 3y agoThis is fascinating, I had never heard of this aspect of JXL.
- deleted 3y ago[deleted]
- magicalist 3y agoThat's just progressive decoding, though, and is only possible if you encoded the image correctly (which is optional). You can also do similar things with progressive jpeg, png, and webp, with jpeg being the most flexible. The unique part AFAIK is that you can order the data blocks however you want, allowing progressive loading that prioritizes more important or higher detailed areas: https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html https://opensource.googleblog.com/2021/09/using-saliency-in-... (your thumbnails may or may not look terrible this way, as well. really better suited for progressive loading)
- lifthrasiir 3y agoThe thing with JPEG XL though is that its design is inherently progressive. Even when there is no reordering you will get 8x downsampled image before everything else (and the format itself exploits a heck out of this fact for better compression).
- cubefox 3y agoApart from limited resolution probably the biggest problem with AVIF: It doesn't support progressive decoding. Which could effectively cancel out its smaller file size for any web applications. AVIF only shows when it is 100% finished. See https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U This comparison video is admittedly a little unfair though, because AVIF would have easily 30% lower file size than JPEG XL on ordinary images with medium quality.
- javier2 3y agoHehe, I see we have been down the same route. Sad to say but ImageMagick is awful at resource usage. VIPS can do 100x better in many specific cases, but is a little brittle. I do not it that incredibly difficult to build though