jonsneyers

Exactly. Image compression should excel at avoiding excess.

Though maybe some people think the JPEG committee is now creating spreadsheet formats...

JPEG XP would have been a nice name for a successor of JPEG 2000, I suppose :)

There's also a JPEG XE now (https://jpeg.org/jpegxe/index.html), by the way.

PNG can and is often used in a lossy way. Reducing the number of colors so PNG8 can be used instead of PNG24/PNG32 is the most common way to do that. Tools like pngquant exist, and for example Photoshop when exporting to PNG also has an option to reduce the colors, to flatten the image (remove alpha), or to change the colorspace.

16-bit PNG files can easily accidentally be reduced to 8-bit, which is of course a lossy operation. Animated PNG files can easily get converted into a still image (keeping only the first frame). CMYK images will have to be converted to RGB when saving them as PNG, which is also a lossy operation. It can happen that an image gets created as or converted to JPEG and then gets saved as PNG - which of course is a bad and lossy workflow, but it does happen.

So I don't agree that with PNG there is no way to accidentally make it lossy.

In any case: lossless or lossy is not a property of a format, but of a workflow. For keeping track of provenance information and workflow history, I would recommend looking into JPEG Trust / C2PA, which is a way to embed as metadata what happened to an image since it was captured/generated. Relying on the choice of image format for this is fragile and doesn't allow expressing the nuances, since reality is more complicated than just a binary "lossless or lossy".

It's technically correct. Googlers (at Google Research Zurich) have been working on jxl-rs, a Rust implementation of JPEG XL. Google Research has been involved in JPEG XL from the beginning, both in the design of the codec and in the implementation of libjxl and now jxl-rs.

But until now, the position of other Googlers (in the Chrome team) was that they didn't want to have JPEG XL support in Chrome. And that changed now. Which is a big deal.

For lossless, bitdepth of course does matter. Lossless image compression is storing a 2D array of integer numbers exactly, and with higher bitdepth, the range of those numbers grows (and the amount of hard-to-compress least significant bits grows).

The OP article is talking about lossy compression.

When comparing lossy compression, note that lossy compression settings are not a "percent" of anything, it's just an arbitrary scale that depends on the encoder implementation. So lossy "80%" is certainly not the same thing between JPEG and JXL, or between Photoshop and ImageMagick, etc. It's not a percentage of anything — it's just an arbitrary scale that gets mapped to encoder parameters (e.g. quantization tables) in some arbitrary way.

The best way to compare lossy compression performance is to encode an image at the quality that is acceptable for your use case (according to your eyes), and then you just look for various codecs/encoders what the lowest filesize is you can get while still getting an acceptable quality.

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.

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).

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)

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.

Assuming the websites are using images of appropriate dimensions (that is, not using huge images and relying on browser downscaling, which is a bad practice in any case), you can quite easily do the math. A 1080p screen is about 2 megapixels, a 4K screen is about 8 megapixels. If your images decode at 50 Mpx/s, that's 25 full screens (or 6 full screens at 4K) per second. You need to scroll quite quickly and have a quite good internet connection before decode speed will become a major issue, whether for UX or for battery life. Much more likely, the main issue will be the transfer time of the images.

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.

It has lossless just to check a box in terms of supported features. A bit like how JPEG XL supports animation just to have feature parity. But in most cases, you'll be better off using a video codec for animation, and an image format for images.

You are right, but that would make an uglier plot :)

Some of the intermediate options are available though, through various more fine-grained encoder settings than what is exposed via the overall effort setting. Of course they will not fall exactly on the line that was drawn, but as a first approximation, the line is probably closer to the truth than the staircase, which would be an underestimate of what can be done.

This matters way more for video (where you are decoding 30 images per second continuously) than it does for still images. For still images, the main thing that drains your battery is the display, not the image decoding :)

But in any case, there are no _major_ differences in decoding speed between the various image formats. The difference caused by reducing the transfer size (network activity) and loading time (user looking at a blank screen while the image loads) is more important for battery life than the decoding speed itself. Also the difference between streaming/progressive decoding and non-streaming decoding probably has more impact than the decode speed itself, at least in the common scenario where the image is being loaded over a network.

Safari/Webkit has added JPEG XL support already.

Firefox is "neutral", which I understand as meaning they'll do whatever Chrome does.

All the code has been written, patches to add JPEG XL support to Firefox and Chromium are available and some of the forks (Waterfox, Pale Moon, Thorium, Cromite) do have JPEG XL support.

Lossless WebP is very good indeed. The main problem is that it is not very future-proof since it only supports 8-bit. For SDR images that's fine, but for HDR this is a fundamental limitation that is about as bad as GIF's limitation to 256 colors.

Both rav1e and libaom have a speed setting. At similar speeds, I have not observed huge differences in compression performance between the two.

No browser bothers with hardware decode of WebP or AVIF even if it is available. It is not worth the trouble for still images. Software decode is fast enough, and can have advantages over hw decode, such as streaming/progressive decoding. So this is not really a big issue.

There are no royalties to be paid on JPEG XL. Nobody but Cloudinary and Google is claiming to hold relevant patents, and Cloudinary and Google have provided a royalty free license. Of course the way the patent system works, anything less than 20 years old is theoretically risky. But so far, there is nobody claiming royalties need to be paid on JPEG XL, so it is similar to WebP in that regard.

If you read the Chromium bugtracker comments (https://bugs.chromium.org/p/chromium/issues/detail?id=117805...) and see the messages of support from e.g. Facebook, Adobe, Intel, VESA, Krita, etc then I think it is quite clear that "no one else is supporting that format" is not quite a correct assessment of the situation.

Those Microsoft patents are not relevant for JPEG XL. Their licensing is therefore also not relevant for JPEG XL.

Actually Safari added support for three new image formats at the same time: JPEG XL, AVIF and HEIC.

JPEG XL uses the ISOBMFF container, with an option to skip the container completely and just use a raw codestream. HEIF is also ISOBMFF based but adds more mandatory stuff so you end up with more header overhead, and it adds some functionality at the container level (like layers, or using one codestream for the color image and another codestream for the alpha channel) that is useful for codecs that don't have that functionality at the codestream level — like video codecs which typically only support yuv, so if you want to do alpha you have to do it with one yuv frame and one yuv400 frame, and use a container like HEIF to indicate that the second frame represents the alpha channel. So if you want to use a video codec like HEVC or AV1 for still images and have functionality like alpha channels, ICC profiles, or orientation, then you need such a container since these codecs do not natively support those things. But for JPEG XL this is not needed since JPEG XL already does have native support for all of these things — it was designed to be a still image codec after all. It's also more effective for compression to support these things at the codec level, e.g. in JPEG XL you can have an RGBA palette which can be useful for lossless compression of certain images, while in HEIC/AVIF this is impossible since the RGB and A are in two different codestreams which are independent from one another and only combined at the container level.

It would be possible to define a JPEG XL payload for the HEIF container but it would not really bring anything except a few hundred bytes of extra header overhead and possibly some risk of patent infringement since the IP situation of HEIF is not super clear (Nokia claims it has relevant patents on it, and those are not expired yet).

Containers are just containers — you still need a decoder for their payload codec. This is the same for video and images. For video, containers are more important because you typically have several different codecs being used together (in particular video and audio) and the different bitstreams need to be interleaved.

The ISOBMFF format is used as a container for MP4, JPEG 2000, JPEG XL, HEIF, AVIF, etc.

And yes, there are ffmpeg-like "uber-libraries" for images: ImageMagick, GraphicsMagic, libvips, imlib2 and gdk-pixbuf are examples of those. They support basically all image formats, and applications based on one of these will 'automatically' get JPEG XL support.

Apple also has such an "uber-library" called CoreMedia, which means any application that uses this library will also get JPEG XL support automatically.