We recently updated IKEA.com to serve AVIFs to browsers that support them where they are smaller for the same level of perceptual quality. Even without Safari support we saw an overall drop in image bandwidth of 21.4% which, considering the amount of traffic we get, is a major chunk of cash saved.
WebKit already supports AVIF directly, but Safari disables that and relies on macOS’s image decoders, which currently don’t.[1] I imagine it’ll arrive at some point.
After my experiments, I came to the conclusion, that for raster images, this is a good combination of srcsets and fallbacks to provide best image quality:
<!-- wrapper element -->
<picture>
<!-- avif srcset: 1x, 2x, 3x as auto select higher quality images for higher screen resolutions -->
<source srcset="/img/articles/iphone-3566282_235.avif 1x, /img/articles/iphone-3566282_235@2x.avif 2x, /img/articles/iphone-3566282_235@3x.avif 3x" type="image/avif">
<!-- webp srcset -->
<source srcset="/img/articles/iphone-3566282_235.webp 1x, /img/articles/iphone-3566282_235@2x.webp 2x, /img/articles/iphone-3566282_235@3x.webp 3x" type="image/webp">
<!-- jpeg also as srcset to provide screen resolution based images -->
<source srcset="/img/articles/iphone-3566282_235.jpg 1x, /img/articles/iphone-3566282_235@2x.jpg 2x, /img/articles/iphone-3566282_235@3x.jpg 3x" type="image/jpeg">
<!-- fallback image with loading=lazy, to load images only when visible -->
<img src="/img/articles/iphone-3566282_235.jpg" alt="Access and recover files from an iPhone on Linux" title="Access and recover files from an iPhone on Linux" loading="lazy" class="size-235 raster ext-jpg" width="235" height="129">
</picture>
I'm seeing some weird behaviour with that on both Chrome 98 and Firefox 97. Chrome seems to be displaying the JPEG, and when I right-click and "Open image in new tab", I get the raw bytes of the AVIF file, not any version of the image. In Firefox, it seems to be displaying the JPEG too, and when I right-click and "Open image in new tab", I get the AVIF file (as an image). Also in Firefox, probably a CSS thing, when the window is made smaller vertically (e.g. by the developer tools at the bottom), the image is scaled down vertically but not horizontally. I'm looking at the image at the top of https://pilabor.com/blog/2021/05/remote-desktop-with-xrdp-an...
Also, upon further investigation, I think both browsers are displaying the AVIF for me. It has quite a bit less detail than the JPEG, so it's identifiable.
Any suggested resources for current best practices for srcset specifically and HTML images in general? I mean for real world use, not just the latest chrome version.
I see some conflicting advice in this thread and from what little I’ve looked into it, there isn’t a good consensus on the subject yet?
In the example given, the image looks far worse with AVIF. Given that this is an F1 car driving with motion blur- the AVIF image looks slow, because now the blur is in every direction.. the wheels appear to have grey liquid dripping from them, and areas of the car that weren't blurred due to being in focal plane, are now mushed and blurred as well!
That's why the only acceptable way to compare codecs is to have two images of exactly the same size. At significantly different sizes, the compression artifacts will be different enough that the comparison becomes subjective, at best.
OP is saying you need them to be the same to make the image quality difference more obvious. If you shrunk the other codecs to the size the AVIF version is at, you’d see much worse visual artifacts. If you increased AVIF to be the same size as the others, you’d get better relative image quality.
The article is trying to demonstrate how much more compression is achieved by trying to keep relative image quality the same. That’s fine normally but when you have a broad population looking at it then it’s going to be a lot of nitpicking which isn’t helpful when you’re trying to communicate about the codec quality (and no benchmark is perfect but it’s pretty clear that AVIF is roughly 20% or better than H265 if I recall correctly - good luck being able to measure a 20% relative difference in image quality by hand).
Exactly. Many people are insensitive to blurring / smearing artifacts, and so what you very often see is a comparison between an old codec at a medium bitrate with noticeable artifacts (e.g. JPEG picking and ringing) and a new codec at a low bitrate with different artifacts that the author just didn't notice. It's no longer a 1:1 comparison. Is the modern codec still better? Probably, but unless the new codec is identical to the old one with less bitrate (hint: it rarely is), you can't prove it with differently sized comparison images.
It cuts both ways though which is what I’m trying to say. Humans can’t say “this artifact is 20% worse”. Everyone has a subjective opinion.
I disagree thought mostly about the codec characterization. H265/AV1 are definitely higher quality at the same bitrate. The test I used is to find the bitrate that artifacts started to be noticeable. H265 was 15-20% smaller bitrate consistently (across multiple people surveyed, not just me). I could definitely believe that AV1 manages a similar feat above that.
I think the artifacts from JPEG and other algorithms are distracting enough that I don't get to consider whether the image is portraying a fast moving vehicle or not. The nitpick you are making is a luxury because you aren't being distracted by the blocky hallucinations of 1992.
I prefer the graininess of JPEG to the overly noise-reduced algorithmic watercolor effect of AVIF, which reminds me of cell phone camera reconstruction algorithms and pinch zoom. Granted it's not a fair comparison because AVIF has a much larger file size.
The image was acceptable for me. What do you want for 15kb? I'd expect a higher quality for click to expand, but this is acceptable to me alongside text content.
> I dont want 15KB, because difference between 15 and 70 is 5 milliseconds.
And I want it, as on travelling or mobile I'm golden if I get 1 MBit/s (= 128 KiB/s) download bandwidth, more often it's around 300-400 KBit/s (37-50 KiB/s), so:
1 MBit/s and one image -> 546 ms vs. 117 ms
300 KBit/s and 1 image -> 1892 ms vs. 405 ms
Most sites have more than one image, say five for some realistic example:
In my residence I'm lucky and get 100+ Mbit/s and even 1 GBit/s at work, but there are lots of countries in the world that don't and once one is affected by that, like I on my train travels, it gets really noticeable which sites have low-bandwidth ignorant engineers, causing not only frustration but often actually impacting life in more meaningful ways negatively.
How would that help me when developers will choose to "optimize" the best version to 15KB? Surely 70KB jpeg will be listed as a fallback. There is no option of defining quality/PSNR/PEVQ/SSIM, only pixel density.
For now that is down to the browser to determine which file to load. From a design perspective, it makes sense to have the HQ image load full screen on click.
Yes, I get that. The problem is there isnt much for the browser to base its heuristics on. Would you send HEAD request for all the listed assets to at least get file sizes? This will be slower and might be even more traffic than just grabbing first one.
Requiring listed size/quality for all the sources might not even be feasible without further automation on the server side, not to mention potential content mangling/"optimizing" proxies/appliances.
HEAD requests seem like the only option aside from inferring size from suggested resolution and format. Imagine trusting the author to include the resource size.
If I could add to the spec, I would put something for lofi/hifi. Then of course that is all subjective and developers will eventually use it in problematic ways.
There's already enough gaming around pagespeed scores. If such an incentive is added, the spec needs to be formulated in an ergonomic way to avoid mal-optimizations.
I agree, either compare at the same size or the same perceptual quality. I know the latter is subjective, but in this case the JPEG is significantly higher quality.
JS disabled here and all I can see imagewise is the single mugshot of the author. Apparently you need javascript to show pictures. Is this deliberate perhaps. I wonder how much the JS weighs.
Personally I'm trying to push for JXL (for high fidelity) and AVIF (for when lower fidelity is acceptable) adoption at work. With absolutely no success yet but as it matures I'm sure things will turn around.
Would love to see an update on this with JPEG XL. I am still not convinced AVIF is the solution. Although libaom made quite a bit of intra-frame / avif specific improvement in the past 2 years so may be worth taking another look.
The main update is that JPEG XL is still not supported out of the box by any web browser, so it's not something you can use just yet. But if you're just looking for a comparison, there's one here: https://afontenot.github.io/image-formats-comparison/
What would the best format to convert user-submitted images? We need to update our image pipeline soon, so I'm looking into various options.
It looks like you still have to keep jpg/png around for a few years at least. Even if you drop IE11, there's a few versions of Safari out there that don't support even WebP.
There are plenty of efforts to improve JPEG compression while retaining compatibility with existing decoders. But there's only so much you can do without breaking decoder compatibility, and if you do that then that's a new format whether you call it JPEG or not. It would be super confusing to have .jpg files that wouldn't work in existing software.
JPEG XL is a new format with a new file extension jxl, but it does have backwards compatibility features that look pretty nice. Maybe that's what you want.
mozjpeg greatly improved the state of art jpeg encodig, while maintaining full backwards compatibility https://github.com/mozilla/mozjpeg
but there's a limit on what can be done with the primitives that jpeg offers. for example, jpeg is stuck with the older huffman coding for the entropy encoding part, instead of the better arithmetic coding or asymetric numeral systems
I understand that AV1 and AVIF are license-free and supposed to be open and available to anyone anywhere, but are there really no catches in the license agreement?
Firefox held off on AVIF for a few releases to get their image color spaces right. I'm usually blind when it comes to things like this (is this random image resized gamma correct? hell if I know), but even I could tell that AVIFs didn't look right before they fixed it. Those fixes were in well before FF 96, so there might be something else at play.
So much stuff fucks with the color profile of the images, the browser, the OS, the screen. I wouldn't be surprised if only some of the test images have a color profile set correctly.
Probably isn't the best idea to compare AVIF to JPEG. JPEG is better suited to high fidelity images, while AVIF is ideal for making the image look good as small as it can.
I suggest looking into JPEG XL for things like photography, scans, etc.
