3 ms·
> In many categories of photos or images, JPEG XL [1] actually does better than AVIF in low bitrate settings. It's not really consistent, but at small sizes JP
by bscphil 4y ago
> In many categories of photos or images, JPEG XL [1] actually does better than AVIF in low bitrate settings.
It's not really consistent, but at small sizes JPEG XL sometimes falls apart, especially if the image contains a lot of smooth textures and clean lines that are easily compressed by AV1. https://afontenot.github.io/image-formats-comparison/#air-force-academy-chapel&avif=t&jxl=t https://afontenot.github.io/image-formats-comparison/#air-fo...
I don't think you need any kind of conspiracy here, AV1 is an open codec after all. The problem is more that (a) AVIF has been around for longer, (b) browsers have to implement most of the spec anyway because they need to have AV1 support, and (c) the hardware decoding story for AVIF is probably going to be better for quite a while, given its closeness to video. AV1 is still a great codec, and Opus is best-in-class for general purpose audio.
Also, I agree with you that optimizing an image codec for high quality use cases is the ideal, but a lot of casual users prefer blurred images with missing detail to noticeable artifacts.
- ksec 4y agoOne of the surprising fact from Cloudflare stats, was that most image on the web are actually 0.7bpp+ with the median being 1.0bpp. So image with 0.24bpp is surpassing small. And that is where progressive decoding works best, showing 0.3bpp image at launch while continue to download other details. There are problematic scenarios with JPEG XL, but I think a lot more could be optimised with encoder once they have 1.0.
- bscphil 4y agoDo you have a link for this? I tried searching for it but couldn't find any details. Mostly I'm wondering if those numbers include just JPEG or also include other formats. E.g. including PNG would tend to drag the median / mean up. Also, if sites are currently using 1.0 bpp JPEGs, I can only assume that they'll want to reduce sizes further when switching to a better codec, since 1.0 bpp is quite low for JPEG. Note that there are samples where JPEG XL still has way too many artifacts at e.g. 1.3 bpp: https://afontenot.github.io/image-formats-comparison/#pont-de-quebec&avif=l&jxl=l https://afontenot.github.io/image-formats-comparison/#pont-d... I do agree with you, though, that if a site is targeting 1.0 bpp or more, they're usually going to see better results with JPEG XL than AVIF. > progressive decoding If I'm not mistaken, it isn't enabled by default for JPEG XL and reduces the encoding efficiency by about 10%.
- ksec 4y agoLate to Reply ( It was Chrome, not Cloudflare, which is arguably more representative ) https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1 https://www.spiedigitallibrary.org/conference-proceedings-of... Figure 1
- bscphil 4y ago> The number of transferred bytes is important because it affects the latency and hence the user experience. Using this estimate, we calculated that between June 1st and 28th, 2019, the average BPP (weighted by the number of bytes transmitted with that BPP) was 2.97, 2.24 and 2.03 for small, medium and large images, respectively. We confirmed that there was no considerable difference between mobile and desktop platforms. This data indicates that image compression algorithms should target rich images with a relatively high BPP values, aiming to produce 1 BPP images almost free of artefacts instead of 0.5 BPP images with artefacts that are not too intrusive. This is excellent, and does indeed suggest that JPEG XL should be broadly preferred in the browser. Thanks for the reference.