This is google+cloudinary published benchmarks of jpeg-xl vs avif vs webp<p><a href="https://storage.googleapis.com/avif-comparison/index.html" rel="nofollow noreferrer">https://storage.googleapis.com/avif-comparison/index.html</a><p><a href="https://cloudinary.com/blog/contemplating-codec-comparisons" rel="nofollow noreferrer">https://cloudinary.com/blog/contemplating-codec-comparisons</a>
Every time I see JPEG XL I always get my wires crossed with JPEG 2000... as in, "Isn't that that weird format I had to use Irfanview to decode?"
If you are curious, here is how JPEG-XL adoption looks like after 42 hours of iOS 17 launch: <a href="https://twitter.com/adityapatadia/status/1704407864326939043" rel="nofollow noreferrer">https://twitter.com/adityapatadia/status/1704407864326939043</a>
JPEG-XL is a fantastic format but it has a big marketing/naming problem. I think the the lack of popularity/adoption is in big parts due to the confusing name.
> JPEG-XL is newest image format and Gumlet is first cloud provider to support it.<p>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.<p>Shame on you for making false claims - especially considering your "service" is in direct competition to cloudinary.
Now... Do we need JPEG-XL in the first place? What's the benefit? Hardware is fast enough to decode JPEG, also storage is cheap enough to stick to JPEG. What's the point in using JPEG-XL if you're not running an imageboard or whatnot?!<p>edit: Happy Birthday, JPEG! We also got 30 years of integration, optimization and everything else for that image format, too.