I have only heard of it in passing. I wonder what it adds beyond Webp and Avif.
Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding.
Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
Where is the software support lacking other than the browsers at this point?
I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.
There's a good visual comparison here:
I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably.
Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.
Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process.
* it actually has better compression than PNG for this
* and potentially AVIF too, but this is debated
Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size.
jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp.
Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG.
What am I misunderstanding here?
https://github.com/dlemstra/Magick.NET/discussions/872
cjxl / djxl do lossless transcode reliably when called with all defaults (no arguments). Just re-checked:
$ cjxl src.jpg out.jxl
(some output)
$ djxl out.jxl rev.jpg
(more output)
$ cmp src.jpg rev.jpg
(no output: files identical)(The IR used to be PixelPacket. Not sure how modern versions handle it.)
Last I checked cwebp still messed up the color space when converting from png so be careful how you use it.
Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
A 1536w / 2048h jpg selfie: 244kb
Progressive JXL at quality=70: 151kb
Loaded 7kb of that file: looked okay up to approx 130px wide.
The first 18kb of that file was a suitable thumbnail up to approx 210px wide.
The first 50kb looked okay up to 300px wide.
The first 75kb looked okay up to 600px wide.
Maybe I need to do a lot more testing, but this seems to work alright?
- people dispute it compresses meaningfully better the types of images typically found on the web.
- progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s.
-flexibility in file formats is usually a bad thing. look at tiff.
personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.
Generally, the approach should always be to prioritize files loading as fast as possible.
Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates.
Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS.
And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts.
> especially AVIF that can't really do lossless RGB
AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC).
> webp ungodly smoothing
There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking.
> libaom is a reference codec thus slow
libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues.
> and not really interested in proper psy optimizations
libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3].
> SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it
No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios.
Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used.
> Progressive decoding
AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away!
The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :)
[1] https://halide.cx/iris/ [2] https://aomedia.googlesource.com/aom/+/refs/heads/av1-normat... [3] https://halide.cx/blog/improving-avif-in-open-source/ [4] https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-... [5] https://jpegxl.info/resources/progressive-loading-demo.html
Bad formulation, the bit that followed those words does detail the "not really" part: compression just takes a massive hit compared to YUV; at least when I tried it last time with libaom (https://news.ycombinator.com/item?id=48359211)
> There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing
Now you're the one being funny. libvpx is famous for its strong PSNR tuning thus preference of blurring over blocking. Even libaom has the same problem.
> libaom (the production encoder) isn’t slow at all, especially for image encoding
Well, that's true that for image encoding, it's alright in performance. Last time I checked, lossless encoding was still way too slow with a decently strong preset (cf first link).
> libaom has psy optimizations
"Some". Since you're one of the people that worked on the psy features now upstreamed into SVT-AV1 (many thanks for that), you know much better than me how libaom has really nothing to match --tune 0.
My bad for using the word "port", but clearly a lot of them like the better aq-modes were conceptualized there.
> AVIF has had progressive encoding/decoding support for years.
Completely forgot that, thanks for the correction.
Maybe I was flaming a bit too much and maybe you're strongly involved in the AV1 world, but "trolling" is a bit much. I followed AVIF since libavif was started by Joe Drago and was really interested in the idea of using a video format's I-frame format to get hwdec/dav1d "for free" and the potential gains from grain synthesis, but the AV1 ecosystem having been so focused on VoD/PSNR and only now starting to be viable for transparency, the lossless/grayscale story being what it is has somewhat made a JXL champion out of me.
jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.