edit: Happy Birthday, JPEG! We also got 30 years of integration, optimization and everything else for that image format, too.
I seriously see JXL as a "keep it for 50 years" codec to replace our aging tech.
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.
On the other hand: When your connection speed is 30 kb/s, images are probably the last problem with "modern" websites... ;-)
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...
Also, your claim is that you are "first to support", not "first to serve all our clients images as jxl without asking if thats ok"...
https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
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.
I pulled all the patches in to Waterfox and have had full support for JPEG XL for nearly a year now.
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.)
> 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.
Perhaps they should have called it JPEG 2.0.
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.
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).
Can add an explicit preload hint but it’s additional complexity
It's probably at least 5 years away though...
