The image [...] is a 116 kB AVIF with a quality score (SSIMULACRA 2) of 62.8, meaning medium-high quality. To get the same quality, the JPEG XL image would be 134 kB.
At a SSIMULACRA 2 score of 80 (very high quality), the AVIF is 227 kB, and the JPEG XL is 264 kB.
But at lossless, the AVIF is 1.76 MB, and the JPEG XL is 1.45 MB. A lossless WebP is 1.55 MB.
At a SSIMULACRA 2 score of 78 (very high quality), the AVIF is 11.6 kB, and the JPEG XL is 23.8 kB.
But at lossless, the AVIF is 164 kB, and the JPEG XL is 92 kB. A lossless WebP is 96 kB.
Although AVIF tends to produce smaller files at web-quality than JPEG XL, AVIF only has basic progressive rendering support. So, for very large images, it may be worth taking the filesize hit with JPEG XL.
= = =
ChoosesBarbecue 54 minutes ago [-]
For all the furore, I think the best outcome happened here. Both browsers used their weight to get a memory-safe implementation out, and now we can all benefit from a new file format with a significantly reduced attack surface.
culi 46 minutes ago [-]
Agreed. It's been hard to watch how much vitriol was pointed at Mozilla for their reasonable position. The C++ decoder was simply unsafe and they would not implement it until a memory-safe decoder was available.
Imagine if the fanatics got what they wanted immediately and then major vulnerabilities were introduced and there was a huge backlash against JXL. It could have set things back way more
ComputerGuru 46 minutes ago [-]
I'm a fan of JpegXL and happy to see support finally begin to coalesce around it on the browser scene, but I was wondering if anyone knew what goes into the decision of whether or not to consider adding encode support, e.g. via offscreenCanvas.convertToBlob() or whatever. How did browsers (minus Safari, of course) end up deciding to add support for WebP encode in addition to JPEG and PNG?
jaffathecake 43 minutes ago [-]
It often comes down to compat, and developer requests. Personally I find in-browser encoding for images inadequate, because it doesn't expose enough options. When we built https://squoosh.app/, we exposed the browser encoders for completeness, but they're pretty bad compared to the wasm codecs.
ComputerGuru 10 minutes ago [-]
I love your editor/comparison tool. Would you be open to adding browser WebP?
Is the JpegXL lossless options the "transparent JPEG recompression" or the actual lossless profile? I'm presuming the latter because it more than doubled the image size.
jl6 42 minutes ago [-]
Great outcome, and I hope the weight of mainstream browser support will spur camera and phone manufacturers to emit native JXLs from their devices.
culi 36 minutes ago [-]
smartphones, computers, and TVs also dedicated hardware acceleration for AVIF video. Decoding an AVIF image uses virtually no battery/CPU power. It will require mass adoption to convince hardware makers to dedicate chips for decoding. especially with AVIF2 on the horizon
14 minutes ago [-]
tristor 31 minutes ago [-]
Nice. I hope we'll see more support for jxl across the web. It's so good at this point that it's my primary output/archival format for all of my photography.
https://groups.google.com/a/chromium.org/g/blink-dev/c/-gDoj...
= = =
= = =Imagine if the fanatics got what they wanted immediately and then major vulnerabilities were introduced and there was a huge backlash against JXL. It could have set things back way more
Is the JpegXL lossless options the "transparent JPEG recompression" or the actual lossless profile? I'm presuming the latter because it more than doubled the image size.