JPEG XL and the Pareto Front

Pay attention to just how good WebP is at _lossless_ comparison though!<p>I&#x27;ve always thought that one as flying under the radar. Most get stuck on WebP not offering tangible enough benefits (or even worse) over MozJPEG encoding, but WebP _lossless_ is absolutely fantastic for performance&#x2F;speed! PNG or even OptiPNG is far worse. And very well supported online now, and leaving the horrible lossless AVIF in the dust too of course.

At the very low quality settings, it&#x27;s kinda remarkable how jpeg manages to to keep a sharper approximation of detail that preserves the holistic quality of the image better in spite of the obvious artifacts making it look like a mess of cubism when examined close. It&#x27;s basically converting the image into some kind of abstract art style.<p>Whereas jxl and avif just become blurry.

I do not understand why this article focuses so much on encode speed, but for decode, which I believe represents 99% of usage in this web-connected world, give a cursory...<p>&gt; <i>Decode speed is not really a significant problem on modern computers, but it is interesting to take a quick look at the numbers.</i>

The inclusion of QOI in the lossless benchmarks made me smile. It&#x27;s a basically irrelevant format, that isn&#x27;t supported by default by any general-public software, that aims to be just OK, not even good, yet it has a spot on one of these charts (non-photographic encoding). Neat.

One does wonder how much of JXL&#x27;s awesomeness is the encoder vs. the format. Its ability to make high quality, compact images just with &quot;-d 1.0&quot; is uncanny. With other codecs, I had to pass different quality settings depending on the image type to get similar results.

It is worth noting that the JPEG XL effort produced a nice new parallelism library called Highway. This library is powering not only JPEG XL but also Google&#x27;s latest Gemma AI models.

Without taking into account whether JPEG XL shines on its own or not (which it may or may not), JPEG XL completely rocks for sure because it does this:<p><pre><code> .. $ ls -l a.jpg &amp;&amp; shasum a.jpg ... 615504 ... a.jpg 716744d950ecf9e5757c565041143775a810e10f a.jpg .. $ cjxl a.jpg a.jxl Read JPEG image with 615504 bytes. Compressed to 537339 bytes including container .. $ ls -l a.jxl ... 537339 ... a.jxl </code></pre> But, wait for it:<p><pre><code> .. $ djxl a.jxl b.jpg Read 537339 compressed bytes. Reconstructed to JPEG. .. $ ls -l b.jpg &amp;&amp; shasum b.jpg ... 615504 ... b.jpg 716744d950ecf9e5757c565041143775a810e10f b.jpg </code></pre> Do you realize how many <i>billions</i> of JPEG files there are out there which people want to keep? If you recompress your old JPEG files using a lossy format, you lower its quality.<p>But with JPEG XL, you can save 15% to 30% and still, if you want, get your original JPG 100% identical, bit for bit.<p>That&#x27;s wonderful.<p>P.S: I&#x27;m sadly on Debian stable (12 &#x2F; Bookworm) which is on ImageMagick 6.9 and my Emacs uses (AFAIK) ImageMagick to display pictures. And JPEG XL support was only added in ImageMagick 7. I haven&#x27;t looked more into that yet.

&gt; The new version of libjxl brings a very substantial reduction in memory consumption, by an order of magnitude, for both lossy and lossless compression. Also the speed is improved, especially for multi-threaded lossless encoding where the default effort setting is now an order of magnitude faster.<p>Very impressive! The article too is well written. Great work all around.

Maybe someone here will know of a website that describes each step of the jpeg xl format in detail? Unlike for traditional jpeg, I have found it hard to find a document providing clear instructions on the relevant steps, which is a shame as there are clearly tons of interesting innovations that have been compiled together to make this happen, and I&#x27;m sure the individual components are useful in their own right!

Missing from the article is rav1e, which encodes AV1, and hence AVIF, a lot faster than the reference implementation aom. I&#x27;ve had cases where aom would not finish converting an image in a minute of waiting what rav1e would do in less than 10 seconds.

The article mentions encoding speed as something to consider, alongside compression ratio. I would argue that decoding speed is also important. A lot of the more modern formats (webp, avif etc) can take significantly more CPU cycles to decode than a plain old jpg. This can slow things down noticeably,especially on mobile.

Does JPEG XL have patent issues? I half remember something about that. Regular JPG seems fine to me. Better compression isn&#x27;t going to help anyone since they will find other ways to waste any bandwidth available.

I really hope this can become a new standard and be available everywhere (image tools, browsers, etc).<p>While in practice it won&#x27;t change my life much, I like the elegance of using a modern standard with this level of performance an efficiency.

I have an existing workflow where I take JPEGs (giant PNGs) from designers and reencode them using mozjpeg. However, I can&#x27;t find a way to invoke jpegli tool in the same way, especially since it seems to just be part of the jpeg-xl tool? Is that right? Are there any sample invocations anywhere?

Looks like there are more savings coming on lossless AVIF: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;AV1&#x2F;comments&#x2F;1b3lh08&#x2F;comment&#x2F;kstmbru&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;AV1&#x2F;comments&#x2F;1b3lh08&#x2F;comment&#x2F;kstmbr...</a>

The problem with JPEG XL is that it is written in an unsafe language and has already had several memory safety vulnerabilities found in it.<p>Image codecs are used in a wide range of attacker-controlled scenarios and need to be completely safe.<p>I know Rust advocates sound like a broken record, but this is the poster child for a library that should never have been even started in C++ in the first place.<p>It’s absolute insanity that we write codecs — pure functions — in an unsafe language that has a compiler that defaults to “anything goes” as an optimisation technique.

This is really impressive even compared to WebP. And unlike WebP, it&#x27;s backwards compatible.<p>I have forever associated Webp with macroblocky, poor colors, and a general ungraceful degradation that doesn&#x27;t really happen the same way even with old JPEG.<p>I am gonna go look at the complexity of the JXL decoder vs WebP. Curious if it&#x27;s even practical to decode on embedded. JPEG is easily decodable, and you can do it in small pieces at a time to work within memory constraints.

Welcome efficiency improvements<p>And in general, Jon&#x27;s posts provide a pretty good overview on the topic of codec comparison<p>Pity such a great format is being held back by the much less rigorous reviews

Should the Pareto front not be drawn with line perpendicular to the axes rather than diagonal lines?

The choice to represent the speed based on multithreaded encoding strikes me as somewhat arbitrary. If your software has a critical path dependent on minimal latency of a single image, then it makes some sense, but you still may have more or fewer than 8 cores. On the other hand if you have another source of parallelism, for example you are encoding a library of images, then it is quite irrelevant. I think the fine data in the article would be even more useful if the single threaded speed and the scalability of the codec were treated separately.

Wow, that new jpegli encoder. Just wow. Look at those results. Haha, JPEG has many years left still.

I&#x27;m surprised mozjpeg performed worse than libjpeg-turbo at high quality settings. I thought its aim was having better pq than libjpeg-turbo at the expense of speed.

Pretty good article, though I would have used oxipng instead of optipng in the lossless comparisons, it&#x27;s the new standard, there.

AVIF looks better here: JPEG XL looks very blurred out on the bottom with high compression. AVIF preserves much more detail and sharpness.<p><a href="https:&#x2F;&#x2F;res.cloudinary.com&#x2F;jon&#x2F;qp-low.png" rel="nofollow">https:&#x2F;&#x2F;res.cloudinary.com&#x2F;jon&#x2F;qp-low.png</a>

JPEG XL is awesome!<p>One thing I think would help with its adoption, is if they would work with e.g. the libvips team to better implement it.<p>For example, streaming encoder and streaming decoder would be the preferred integration method in libvips.

It is nice 0.10 finally landed those memory and speed optimisation.<p>But the King remains HALIC. In terms of MT encoder it still uses 3.5x more memory than HALIC, and 6x encoding time compared to HALIC. While offering the same or smaller files size in Lossless. Hopefully JPEG XL could narrow those gaps some days.

How is lossless webp 0.6th of the size of lossless avif? I find it hard to believe that.

&quot;Pareto&quot; being used outside the context of Brazil&#x27;s best prank call ever (Telerj Prank) will always confuse me. I keep thinking, &quot;what does the &#x27;thin-voiced lawyer&#x27; have to do with statistics?&quot;...

If only Google could be convinced to adopt this marvelous codec... Not looking super positive at the moment:<p><a href="https:&#x2F;&#x2F;issues.chromium.org&#x2F;issues&#x2F;40270698" rel="nofollow">https:&#x2F;&#x2F;issues.chromium.org&#x2F;issues&#x2F;40270698</a><p><a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=1451807&amp;no_tracker_redirect=1" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=145180...</a>