Why?
To start things off, I have been a fan of the AVIF image format since I heard about it, not long after I started learning about the AV1 video codec in 2020. I figured the fact that it was backed by the Alliance for Open Media, was the natural successor to WebP, and was based on a rather powerful video codec that was rapidly growing in popularity was great for users & organizations alike to easily understand what the technology stood for, where it came from, and what benefits it provided over the existing lossy image king, JPEG. Good codecs are open source codecs, so the fact that AVIF was open source was a big deal to me as well. It is also already widely supported at the time of writing. I thought unequivocally that AVIF would be the future of images on the web when I first learned about it. I don’t think I was entirely wrong, but I hadn’t yet heard of JPEG-XL.
JPEG-XL (JXL for short) is an image codec by the JPEG committee (yes, the JPEG committee). Initially I hadn’t thought much of the codec because the compression efficiency was “the same as AVIF,” so I kind of wrote it off, as I’m sure many uninformed people have & continue to do. Upon doing more research, my position flipped and I found myself deeply invested in the future of JXL.
JXL’s fascinating features include the highly efficient variable-blocksize discrete cosine transform (which is superior to JPEG’s DCT), usage of the XYB colorspace which more accurately represents the response our cones in our eyeballs have to different wavelengths of light, & a “modular” mode for efficient lossless or near-lossless coding. It is also used while encoding lossy JPEG-XL images, but I don’t know much about it & I won’t pretend to. Currently the reference encoder also supports patch detection, noise synthesis, and will (probably) eventually support spline detection as it is present in the codec specification. JPEG-XL also supports lossless JPEG transcoding that reduces the filesize of JPEGs which in my opinion is a game-changing feature. That alone could be a revolutionary codec by itself. Progressive decode is also a standout feature of JPEG-XL, and I found this article very interesting regarding that.
Some more interesting JXL articles & resources:
www.roboleary.net/webdev/2023/03/06/next-web-image-format-not-jpegxl.html
tonisagrista.com/blog/2023/jpegxl-vs-avif
cloudfour.com/thinks/on-container-queries-responsive-images-and-jpeg-xl
motionmill.com/2023/02/google-stopt-jpex-xl-gebruiken
ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf
cloudinary.com/blog/the-case-for-jpeg-xl
Also worth noting is the format’s most outspoken pioneer Jon Sneyers (co-author of the JPEG XL spec) as well as other noteworthy developers are extremely active within the community and value the feedback of the people who are passionate about their work. This should not be as unique as it is, but it is incredibly valuable to have one’s voice heard so easily & frequently by developers who actually care. I commend Sneyers & the other core JXL devs for this.
Anyway, TL;DR: JXL has a lot more to offer than just good compression. But, I still wish to know; how does it stack up against other image formats regarding lossy compression & lossless compression?
Methodology (Photographic Corpus)
In order to produce an unbiased test to determine how good JPEG-XL is relative to my needs, I took 27 photos (mostly consisting of landscape/architecture photography) around my seaside hometown using my Sony a5000 at 20.1mp, edited them in Darktable, exported them as 16-bit sRGB PNGs (AdobeRGB had some problems), & finally I ran a script written by my friend RootAtCali (check out their cool site) to determine each image format’s SSIMULACRA2 scores for each quality level available via the format’s lossy coding option.
I’ll be certain to make my lossless sources available via an edit to this post, & they’ll be linked at the top. In the meantime, here’s another page with full resolution lossy JXL photos encoded at -d 1.0. The images are under CC-BY-SA 4.0.
