2 ms·
JPEG XL can be fully implemented in 50-150 kB, and now you tell that AVIF implementations in browsers at 500+ kB are bare minimum subsets.
by JyrkiAlakuijala 4y ago
JPEG XL can be fully implemented in 50-150 kB, and now you tell that AVIF implementations in browsers at 500+ kB are bare minimum subsets.
- pornel 4y agoThe major cost is on the AV1 side, which is there for video and which JPEG XL can't replace. The extra cost of recycling existing MP4+AV1 code to handle AVIF is minimal, smaller than JPEG XL can be.
- jonsneyers 4y agoThen again, libjpeg-turbo could probably be dropped if we spend some effort on making libjxl also decode jpegs (and encode them, since browsers also need to do be able to do that for jpeg). I think that could reduce the net cost of adding jxl quite a bit — libjpeg-turbo has quite some code and API functions that browsers don't actually need at all, and all it really needs to do is already there in libjxl. So a variant of the "two for one" argument that justifies AVIF can also be used to justify JXL, since JPEG is needed anyway, even more so than AV1. Also I am not so sure if the delta between AV1-only and AVIF is _that_ small, after all you do need to take care of alpha, color management, HDR, animation, and I suppose quite different code paths to get the decoded pixels in the right place than what is already there for the video case. Plus it looks like new things are still getting added to avif, like YCoCg-R and progressive previews, so it feels like it's a bit of a "moving target" spec like webp was in the early days. I see quite a few opportunities for bugs, different levels of support between different browser (versions), etc, that are not caused by AV1 itself but just by AVIF.