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.
First automatic JPEG-XL cloud service
41–50 of 68 posts
Re: First automatic JPEG-XL cloud service
#42Now... 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?! edit: Happy Birthday, JPEG! We also got 30 years of integration, optimization and everything else for that image format, too.
Don't ignore the fact that unlike WebP (lossless: missing grayscale | lossy: forced 4:2:0 chroma subsampling =x | both: missing metadata and progressive) and AVIF (lossless: worse than PNG in many cases, i.e. useless), it's both a very good PNG and JPEG replacement; only AVIF wins in my books are very low bpp lossy quality (not very interesting), hardware decoding support and dav1d being amazing.
I seriously see JXL as a "keep it for 50 years" codec to replace our aging tech.
Re: First automatic JPEG-XL cloud service
#43Any insight on why Firefox and Chrome dropped it, other than how disappointing it felt? What was their reason?
Firefox still supports it - there are even pending patches for animation support. Unless it has recently changed, it’s only available on nightly builds + a preference toggle.
I pulled all the patches in to Waterfox and have had full support for JPEG XL for nearly a year now.
Re: First automatic JPEG-XL cloud service
#44This is google+cloudinary published benchmarks of jpeg-xl vs avif vs webp https://storage.googleapis.com/avif-comparison/index.html https://cloudinary.com/blog/contemplating-codec-comparisons
From my own tests. JXL is better for photos and competitive with AVIF for images with flat areas of color (PNG-like). JXL is about the same speed as AVIF but WebP is quicker than both.
Is this your test, just in case? https://ache.one/articles/web-image-formats
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.)
Re: First automatic JPEG-XL cloud service
#45If you are curious, here is how JPEG-XL adoption looks like after 42 hours of iOS 17 launch: https://twitter.com/adityapatadia/status/1704407864326939043
What does that show? Adoption where? By whom?
Re: First automatic JPEG-XL cloud service
#46Earlier quoted context omitted.
The biggest advantage I can think about is transparency support.
Ok, but we got PNG for that. Photos usually don't contain transparencies, so why have several Megapixel/Megabyte large PNGs?
Why not have one format good for everything image? There's zero reason to not have it now. Would you say 'We got GIF for that' if asked for animation?
Re: First automatic JPEG-XL cloud service
#47If you are curious, here is how JPEG-XL adoption looks like after 42 hours of iOS 17 launch: https://twitter.com/adityapatadia/status/1704407864326939043
What does that show? Adoption where? By whom?
I guess adoption of browsers capable of displaying JPEG-XL as part of the overall browser landscape
Re: First automatic JPEG-XL cloud service
#48Can't wait for my cameras to output jpgxl files natively!
It's probably at least 5 years away though...
Re: First automatic JPEG-XL cloud service
#49Now... 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?! edit: Happy Birthday, JPEG! We also got 30 years of integration, optimization and everything else for that image format, too.
High quality progressive decoding at reduced filesizes is a big positive for me. There is no other format that supports that. https://www.youtube.com/watch?v=UphN1_7nP8U
> High quality progressive decoding at reduced filesizes is a big positive for me.
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.
Re: First automatic JPEG-XL cloud service
#50> JPEG-XL is newest image format and Gumlet is first cloud provider to support it. 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.
Founder here. We are first cloud service to do it "automatically" based on client support. Most services don't have this and those who have it, don't do it automatically and requires code change.
Cloudinary is providing it now but, for the moment, you have to request that it be added when you use the `f_auto` ("auto format") transformation.