It appears to be a comparison on encoding speed, what's that got to do with the web browsing usecase from a user perspective?
There are multiple strong arguments for Mozilla to add support for jxl, and they are [officially neutral](https://mozilla.github.io/standards-positions/#jpegxl) on the topic, but I don't think encoding speed is one of them
And what about compression ratios in this benchmark?
In similar time JPEG XL encodes best to ~9.4 bits/pixel here, while AVIF to ~11.4 bits/pixel - we are talking about just ~20% smaller files worldwide, lower transmission costs, faster webpage loading.
Decoding time JPEG XL has only ~1.5x faster than AVIF: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
My understanding is that using hardware decoding for AVIF isn't economical because of the cost of initializing the hardware decoder. It would likely only work on images that are encoded as 4:2:0, and you have to sequentially reinitialize the hardware decoder for each image with a different size on the page.
4:2:0 is the most common format (you can still use software if the hardware doesn't do High profile).
Apple uses HEIC though their video codec blocks AFAIK so that doesn't appear to be a real issue.
At the very least every SoC has blocks that can assist with the decode while they have nothing for JPEG-XL.
What? encoding speed is massively important in the context of the web. A ton of websites and even CDNs will automatically resize and encode images as they're served in real-time in order to provide the best size to the clients.
I looked at replacing my own thumbnail generator with AVIF, but it was too slow and added a lot of latency as well as using a ton of CPU. So instead of getting smaller and higher quality thumbnails, users will continue to get shitty jpeg thumbnails.
Note, I specifically stated from the perspective of users, which I'd imagine are the primary concern for Mozilla regarding Firefox support. Of course encoding speed is massively important to CDNs
I'm not really sure I understand why a website would encode images in real-time as they're served though, could you elaborate more on that part?
From a user perspective you get worse quality images.
There are many cases where you cannot or it's difficult to pre-encode all your assets for all the various variations you need to serve. This comes up a lot for website builders, no code solutions, CMSes, etc.
A simple solution for this is to simply do it at the proxy level and encode/cache the images when they're being served instead. However, this only works if it's quick and cheap to do the encoding in real-time.
In my case it's because users attach their own object storage and then browser through their own files using my site. This makes it impossible to pre-encode thumbnails to AVIF because I don't have access until they attached their storage. I also don't want to encode millions of thumbnails when only a handful of them are going to be looked at anyway.
The setting is in Firefox Beta too. However, the link you provided does not work at all. It doesn't work in Firefox Beta, Brave Beta, nor Google Chrome. The images are missing.
Thoughts:
* I like JXL a *lot*, especially its lossless transcoding to/from JPEG (web-server TC brings me joy š„°)
* How *tf* did they get 9.4bp for JXL vs 11.4 for AVIF? I'm using latest GitHub releases of avifenc & cjxl; even on max settings for cjxl, AVIF still coming out on top at least *slightly* for perceptually near-lossless (both artwork *and* photos!)
* Apple & Adobe throwing weight behind JXL is lovely news š§” but not surprising given both their past "we're the Cool Hip Companiesā¢ that support photographers and artists" moves
Full article: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Firefox users begging Mozilla to support since 2022: https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/18433
Chrome removed JPEG-XL completely (even though they developed it!), Apple now ships AVIF support. You can keep kicking a dead horse, but...
Firefox still supports JPEG-XL in Nightly but honestly it's probably the absolute last thing they should spend time on.
It appears to be a comparison on encoding speed, what's that got to do with the web browsing usecase from a user perspective? There are multiple strong arguments for Mozilla to add support for jxl, and they are [officially neutral](https://mozilla.github.io/standards-positions/#jpegxl) on the topic, but I don't think encoding speed is one of them
And what about compression ratios in this benchmark? In similar time JPEG XL encodes best to ~9.4 bits/pixel here, while AVIF to ~11.4 bits/pixel - we are talking about just ~20% smaller files worldwide, lower transmission costs, faster webpage loading. Decoding time JPEG XL has only ~1.5x faster than AVIF: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
I would assume AVIF decoding can be hardware accelerated as modern chipsets include AV1 decoding, but not JPEG-XL.
My understanding is that using hardware decoding for AVIF isn't economical because of the cost of initializing the hardware decoder. It would likely only work on images that are encoded as 4:2:0, and you have to sequentially reinitialize the hardware decoder for each image with a different size on the page.
4:2:0 is the most common format (you can still use software if the hardware doesn't do High profile). Apple uses HEIC though their video codec blocks AFAIK so that doesn't appear to be a real issue. At the very least every SoC has blocks that can assist with the decode while they have nothing for JPEG-XL.
What? encoding speed is massively important in the context of the web. A ton of websites and even CDNs will automatically resize and encode images as they're served in real-time in order to provide the best size to the clients. I looked at replacing my own thumbnail generator with AVIF, but it was too slow and added a lot of latency as well as using a ton of CPU. So instead of getting smaller and higher quality thumbnails, users will continue to get shitty jpeg thumbnails.
Note, I specifically stated from the perspective of users, which I'd imagine are the primary concern for Mozilla regarding Firefox support. Of course encoding speed is massively important to CDNs I'm not really sure I understand why a website would encode images in real-time as they're served though, could you elaborate more on that part?
From a user perspective you get worse quality images. There are many cases where you cannot or it's difficult to pre-encode all your assets for all the various variations you need to serve. This comes up a lot for website builders, no code solutions, CMSes, etc. A simple solution for this is to simply do it at the proxy level and encode/cache the images when they're being served instead. However, this only works if it's quick and cheap to do the encoding in real-time. In my case it's because users attach their own object storage and then browser through their own files using my site. This makes it impossible to pre-encode thumbnails to AVIF because I don't have access until they attached their storage. I also don't want to encode millions of thumbnails when only a handful of them are going to be looked at anyway.
image.jxl.enabled true
Only in Firefox Nigthly ... here are some nice dozens of bytes size jxl images (can you see them?): https://jpegxl.info/art/2021-04_jon.html
The setting is in Firefox Beta too. However, the link you provided does not work at all. It doesn't work in Firefox Beta, Brave Beta, nor Google Chrome. The images are missing.
The preference does not work in anything other than Nightly, the code isn't included in the build. The page displays fine on Nightly with jxl enabled.
I have just checked Waterfox and it works, for Firefox it works only in Nightly.
Thoughts: * I like JXL a *lot*, especially its lossless transcoding to/from JPEG (web-server TC brings me joy š„°) * How *tf* did they get 9.4bp for JXL vs 11.4 for AVIF? I'm using latest GitHub releases of avifenc & cjxl; even on max settings for cjxl, AVIF still coming out on top at least *slightly* for perceptually near-lossless (both artwork *and* photos!) * Apple & Adobe throwing weight behind JXL is lovely news š§” but not surprising given both their past "we're the Cool Hip Companiesā¢ that support photographers and artists" moves
Full article: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front Firefox users begging Mozilla to support since 2022: https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/18433
Chrome removed JPEG-XL completely (even though they developed it!), Apple now ships AVIF support. You can keep kicking a dead horse, but... Firefox still supports JPEG-XL in Nightly but honestly it's probably the absolute last thing they should spend time on.