Thanks!

Yes, my hope is that jxl can become an interoperable format for layered images. It does not have all the functionality of image editor formats (PSD, XCF, etc), but it does have a very useful subset of that (named layers with basic blend modes). For interchange, it would be very suitable since it has state of the art compression (both lossy and lossless), does not force you to merge the layers before exporting, while the images can be viewed directly by any application that supports jxl — since the blending happens inside the decoder, the viewing application can be blissfully unaware that it even is a layered image, it will just get the merged image from the decoder if it doesn't ask for the individual layers.

This article is from 2020. I think so far it has aged reasonably well. But you might be interested in my more recent articles too. You can find those here: https://cloudinary.com/blog/author/jon_sneyers

Last time I tested, libjxl e1 had a better compression ratio than default libpng, while being two orders of magnitude faster. See https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the...

The point of reference here is not PNG but lossless JPEG, which was the best available option in DNG before version 1.7 of the DNG spec. Lossless JPEG compresses worse (but faster) than PNG.

I don't know how HALIC works but if there is no FOSS implementation available that seems like a no-go.

Lossless compression is not about importance of data. Lossless is lossless, if the result of a roundtrip is not EXACTLY IDENTICAL then it is by definition not lossless but lossy.

Maybe you're confusing with "visually lossless" compression, which is a rather confusing euphemism for "lossy at sufficiently high quality".

JPEG XL can do both lossless and lossy. Lossless JPEG XL, like any other lossless image format, stores sample values exactly without losing anything. That is why it is called "lossless" — there is no loss whatsoever.

JPEG XL is a royalty-free codec and "generating revenue streams" was never a goal for the project. You can see this already in the very first draft call for proposals from 2017: https://jpeg.org/downloads/jpegxl/jpegxl-draft_cfp.pdf (see section 5 on page 7)

Which is my point: "JPEG XL" is "too little too late" after JPEG tried to monetize its brand with various other, pretty much failed initiatives:

- JPEG 2000 is popular in the medical imaging space but everywhere else shunned like the patented abomination it is until the patents fizzled out.

- JPEG XR is covered by Microsoft's patents that are supposedly defused under a "covenant not to sue" (but not really).

- JPEG XT builds on JPEG 2000 with all its money-grubbing problems.

- JPEG XS is a pretty particular beast regarding its use cases, but nevermind, there's a patent pool. As such it won't become popular before 2040.

Only with JPEG XL (2017) did they _finally_ acknowledge that they're working on standards that everybody avoids to the best of their abilities due to the licensing situations JPEG optimized for. 20 years for naught.

At that point WebP (whose ancestry makes it explicitly a part of the "avoid the patent mess" movement) was already out for 7 years.

The above claims are not very accurate.

JPEG and JPEG 2000 were based on the principle that the core codec was royalty-free but there might be patent-encumbered optional things (such as arithmetic coding, in the case of JPEG) that could be just left out if you want a royalty-free codec. Eventually it became clear that basically a de facto standard would always emerge that just skipped the patent encumbered things; JPEG XL doesn't have any (known) patent-encumbered ingredients for that reason: it's a bit pointless to add things to the spec that nobody will want to use anyway.

I don't think patents played a big role in the (lack of) adoption of JPEG 2000 and JPEG XR; more likely, in my opinion, the main problem was that good FOSS implementations were not readily available at the right time. The core codec of J2K has been royalty-free from the start, but it took quite a while before good FOSS software (like OpenJPEG) was available. Computational complexity was also an issue in its early days. For JPEG XR, even today there is no well-maintained FOSS implementation available; this is probably a bigger reason for its lack of popularity than potential patent issues. Compare for example with h264 (and x264), which had more substantial patent issues but nevertheless became very popular.

JPEG XT builds on JPEG, not JPEG 2000.

JPEG XS has a very specific niche use case (ultra-low latency, as a mezzanine codec for video production workflows), it doesn't have the goal of 'becoming popular' as a general-purpose codec.

JPEG is not MPEG. While both are working groups of ISO, which does have a policy that is not exactly "avoid the patent mess" but rather "don't talk about IP", there is quite a big difference in membership composition and attitudes between those two groups. Having a royalty-free baseline codec (and more recently, having just a completely royalty-free codec) has been something JPEG has been pursuing since the beginning (1980s), while in MPEG they're only recently coming to that conclusion (with EVC, no doubt due to pressure from initiatives like AOM).

Chair of the JPEG XL adhoc group of JPEG here.

I wasn't around when the name for this project was chosen (I only got involved after the call for proposals, at which point the codec already had a name even if it didn't exist yet). I haven't been able to track down the actual etymology or rationale for the name, though "Long-term" has been suggested to be the main interpretation.

I think the name was to some extent chosen as a tongue-in-cheek pun because obviously compression is about making large things smaller. The name must have been chosen around the time that there was a lot of activity around JPEG XS. That codec is all about speed and low complexity, which is where the S comes from: it is very fast (so S for speed) and also it has a relatively simple and small implementation (in terms of circuit complexity), since it is designed for hardware.

So in contrast to JPEG XS, JPEG XL is actually "extra large" in the sense that it does have more complexity, more coding tools, more functionality. All those things are of course there with the goal of making smaller files, but the codec itself is "extra large" compared to JPEG since it has all the coding tools of JPEG plus a bunch more. So in that sense, JPEG XS is indeed "extra small" and JPEG XL is "extra large", as a codec, but in terms of the sizes of the compressed images, it's exactly the other way around: JPEG XS will produce larger files (it sacrifices compression for simplicity/speed/latency), JPEG XL will produce smaller files.

I agree that all this is quite confusing. If it helps, you can always just call it by its filename extension / media type instead of its full name: "jxl".

Thanks for the suggestion, oxipng is indeed a better choice. Next time I will add it to the plots!

It is unlikely that there will be any bitstream changes in JPEG XL. There is still a lot of potential for encoder improvements within the current bitstream, both for lossy and for lossless.

No it doesn't.

And yes, regular JPEG is still a fine format. That's part of the point of the article. But for many use cases, better compression is always welcome. Also having features like alpha transparency, lossless, HDR etc can be quite desirable, and those things are not really possible in JPEG.

Humans generally tend to prefer smoothing over visible blocking artifacts. This is especially true when a direct comparison to the original image is not possible. Of course different humans have different tastes, and some do prefer blocking over blur. SSIMULACRA2 is based on the aggregated opinions of many thousands of people. It does care more about blur than metrics like PSNR, but maybe not as much as you do.