> JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory. So why not just use that to build your own computer architecture and script that!? That's exactly what this exploit does. Using over 70,000 segment commands defining logical bit operations, they define a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations. It's not as fast as Javascript, but it's fundamentally computationally equivalent.

> The bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream.

https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

Incredible programming.

cjxl input.jpg output.jxl

The cjxl --help and cjxl -v -v --help pages are very well done and you'll find the option to explicitly set the option on if you wish to do so.

> Specifically for JPEG files, the default cjxl behavior is to apply lossless recompression and the default djxl behavior is to reconstruct the original JPEG file (when the extension of the output file is .jpg).

magick input.jpg output.jxl

https://storage.googleapis.com/avif-comparison/index.html

https://cloudinary.com/blog/contemplating-codec-comparisons

Instead of using a breakpoint style approach with several predefined sizes some site generate images related to viewport size at very fine granularity and even changing the viewport by 1px will cause the AVIF to be regenerated

In these cases you can notice services like Cloudinary take several seconds to generate the new variant if it’s a large image

I'm not very sure how you have compared the speed. `cjxl -e 9` for example is known to be very slow because it is AFAIK basically `-e 8` with a brute-force parameter search (and I think this level should be hidden in some way for this exact reason, it is very misleading). Also I assume that you have done an end-to-end command line test with relatively small inputs, which might be a major pitfall (because it doesn't only measure the PNG encoder/decoder but also all program invocation time and finalization time, which can be specficially optimized [1]).

Also only relying on a single objective metric might be misleading, and Jon Sneyers (one of JPEG XL devs) has a very good plot that illustrates this [2] and pointed out that actual images have to be also manually reviewed to reduce mistakes. Many comparisons are made against images with similar SSIM scores, but it is unclear if they indeed had similar qualities. And an ideal perceptual metric is not enough, specifics on "taking the AVIF format points as a basis and comparing them with the similarity and similar ratio points" would be necessary to evaluate the test.

[1] For example you can skip `free` on complicated structures because they will be reclaimed by the kernel anyway. Of course this is totally unacceptable for libraries.

[2] https://twitter.com/jonsneyers/status/1560924579719258113 (The ideal metric should strongly correlate to the human score and should not distort the relative score difference. Most metrics---except for SSIMULACRA 2 which specifically being developed with this dataset---are bad at both.)

Can add an explicit preload hint but it’s additional complexity

This is completely untrue. Cloudinary have supported it since 2020, which is where Jon Sneyers, the chair for the JPEG XL WG and lead developer of libjxl works.

Shame on you for making false claims - especially considering your "service" is in direct competition to cloudinary.

>Google snubbed JPEG XL so of course Apple now supports it in Safari

The "hedge" angle on doing what google isn't doing is a fascinating possibility.

Could it be that, paradoxically, Google actually inadvertently secured JPEG-XL's future by ripping it out of Chrome?

https://cloudinary.com/documentation/image_optimization#auto...

You dont need to use the f_jxl parameter. e.g. https://res.cloudinary.com/demo/image/upload/c_scale,w_500/f...

edit: Happy Birthday, JPEG! We also got 30 years of integration, optimization and everything else for that image format, too.

https://www.youtube.com/watch?v=UphN1_7nP8U

On the other hand: When your connection speed is 30 kb/s, images are probably the last problem with "modern" websites... ;-)

Current browser support where available is a lot more restrictive TBH, as you dont have any control over that behaviour. But outside the browser its solid gold.

This is really cool!

Honestly, I want to use regular progressive JPEGs for a current project of mine, but it seems that even that doesn't have support in all the tech stacks yet despite how long it's been around for, for example: https://github.com/SixLabors/ImageSharp/issues/449

Here's hoping that in the case of JPEG-XL this will be more commonplace! In combination with loading="lazy", it would surely make the experience of scrolling through modern sites with lots of content a bit less data intensive.

In the browser where supported, I guess loading="lazy" probably already works (i havent tried). I think a more advanced version where you can choose maybe a "staged" loading type, or some mechanism to choose the pass/frame to pause the network activity at so that you can control it further via JS would be nice. At a minimum it would be a feature enabling a preview and a reduced download for the full version. I can see many usecases where that could be useful.

I seriously see JXL as a "keep it for 50 years" codec to replace our aging tech.

I mean, Webp must store an RGBA tuple for each pixel, even for grayscale without alpha, right?

A perfectly reasonable decision if made by a committee of disinterested parties deciding the future of the web for the benefit of humanity, but a bad look when pulled by a megacorp.

For Firefox, it's about hoping to get to that latter situation. They want the web to move forward in step as much as possible rather than it being some wild west where everyone just does their own thing. They've lived through that already. And it sucked. Hence the various standardisation and community interoperability measures which have radically improved the web platform over the last decade or so.

https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

I pulled all the patches in to Waterfox and have had full support for JPEG XL for nearly a year now.

JPEG XR (Windows Media Photo, hdr), JPEG XS (a "realtime" one) and JPEG XT (a "very backwards compatible" one). So besides XL I'm never sure what the hell I'm dealing with.

Perhaps they should have called it JPEG 2.0.

It's probably at least 5 years away though...