| > The argument is: (1) the cost is large -- implementation and maintenance of a complex image codec takes time, and image codecs are high-risk from a security perspective. If you look at the history of Google employees created the basis for JPEG XL [1], having it included in beta builds of Chrome and then removing it "for reasons", it's pretty obvious it wasn't pulled for technical or security reasons. Obviously Apple didn't think there were significant security and implementation issues preventing them from enabling JPEG XL on over 2 billion devices. The Chrome team has proposed a number of web features and APIs that Apple, Mozilla and sometimes Microsoft don't want to implement due to security and privacy reasons. Usually that doesn't stop Chrome from going ahead and shipping them anyway. > (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases. JPEG XL does provide advantages over existing alternatives—The Case for JPEG XL [2]: In the past, new image formats have been introduced that brought
improvements in some areas while also introducing regressions in
others. For example, PNG was a great improvement over GIF,
except that it did not support animation. WebP brought
compression improvements over JPEG in the low to medium fidelity
range but at the cost of losing progressive decoding and
high-fidelity 4:4:4 encoding. AVIF improved compression further,
but at the cost of both progressive decoding and deployable
encoders.
We looked at six aspects of JPEG XL where it brings significant
benefits over existing image formats:
* Lossless JPEG recompression (20% on average)
* Progressive decoding
* Lossless compression performance
* Lossy compression performance
* Deployable encoder
* Works across the workflow
[1]: https://github.com/google/pik[2]: https://cloudinary.com/blog/the-case-for-jpeg-xl |
> Lossless JPEG recompression (20% on average)
Lossless JPEG recompression isn't that valuable because it's a "tweener" solution. If you mainly just care about image size, you can live with some loss and can recompress jpegs using existing formats. Or if you care about size and quality, you can recompress from high-quality sources using existing formats. lossless jpeg recompression kind of fits in the middle somewhere... you care enough about size to go through the trouble to recompress, but you don't care so much that you will use high-quality sources and you care about quality enough that you don't want to lose quality when recompressing, but again not so much that you will use high-quality sources. So it's not nothing, but not great either.
> Progressive decoding
A solution to a vanishing edge case.
> Lossless compression performance
Explains why you might want to use jxl in your workflow but that's not a browser concern.
> Lossy compression performance
This sounds good, but is it enough better over existing formats to justify a new one in the browser? I don't think it's clear cut.
> Deployable encoder
Obviously, existing formats have deployed encoders.
> Works across the workflow
Not a browser concern. Note that even if you use jxl across your entire workflow, you're still going very typically have a publishing step for images where you find and use a level of compression/quality appropriate for your project. There's not really any particular difference if the general image format type has changes at this step or not.