Isn't it the purpose of the "Accept" HTTP header? For example the last version of Firefox sends "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8" when fetching a page.
If you can do avif with better results than webp then do that.
You can also vary on the data save if you are really keen.
* it seems fixable with things like Lambda@Edge and I wouldn't be surprised if a smart CDN which already does on-the-fly image compression had implemented this too
Likely not. Chrome is actually deprecating JPEG XL, the news broke yesterday.
This sucks.
> - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL - The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
I ran some benchmarks with a raw 48mp iPhone 14 dng file (converted to png to start with since jxl had issues going from dng directly) with imagemagick to illustrate.
jpg conversion: 1.74s
webp conversion: 3.77s
avif conversion: 67.96s
jxl conversion: 42.74s
Of course there's ways to optimize these, but still it's worth considering that these newer formats require an order of magnitude (if not more) increase in time to encode. If you're doing this for your own static site, it's worth doing. If you're dealing with user submitted images, make sure you understand the tradeoffs.
Distance is the target perceptual metric (Butteraugli), while effort controls a variance of the perceptual metric of the encoded image---which can be never accurate. Higher effort means more consistent quality but more computation as well. The default for cjxl, and probably also ImageMagick, is 7 ("squirrel"), which is very high and very slow as you noted. This is much like Brotli defaulting to the highest setting (-11) because both assume that you can spend much more time in compression. If it's not your assumption you should change that.
I do feel that this aspect of JPEG XL is not well communicated. Normally you have a single knob (quality) and increasing quality means more time spent for compression, but in JPEG XL this can be easily decoupled---very useful concept but also relatively alien one. A common mistake is to set the highest effort (9, nicknamed quite appropriately, "tortoise") for speed benchmark, which suggests that there will be people doing this in the production and complaining that JPEG XL compression is very slow, not realizing they can live with much lower efforts.
Holy shit-balls? Also I thought that quad bayer would come down to 12MP for the output?
In combination with static hosting from S3 with CloudFront for caching, handwritten CSS + JS (except from Turbo), this yields a close-to-SPA snappiness and feel even on meager connections (as tested from rural Germany, fellow Germans may understand the implications).
The picture tag and the aspect-ratio CSS rule are real MVPs for dealing with photographs.
[1] https://44hz.de
I try that, but don't end to work fine, thanks to the alt text showing, and displacing the background placeholder image
It's disappointing that browser vendors haven't picked up on this and offered a "Save as PNG/JPEG/GIF" option when downloading images, but for now if it seems reasonable that if any user would want to download an image you're displaying then you should probably stick to the legacy formats.
Couldn't one do the same thing to make users get jpegs when they try to save a wepb? How bad would it be?
Certainly not the case with WebP, which was announced by Google 12 years ago. On a recent version of macOS, Preview, the Mac’s default image and pdf viewer can open WebP and AVIF files, making it easy for Mac users to convert to another format if they wish. Also 3rd party graphics apps have supported WebP for years now.
AVIF support isn’t as widespread yet but that will quickly change now.
BTW, the iOS defaults to saving photographs in HEIC, which the average consumer has never heard of.
This only loads the image when it scrolls into view
With iOS 16, current one, and newest Safari with macOS Ventura that support was added, see https://caniuse.com/avif
$ curl -s https://jfhr.me/your-browser-supports.avif | file -
/dev/stdin: PNG image data, 400 x 100, 8-bit grayscale, non-interlaced
The final <img> tag also specifies common attributes like width, height and alt text. Those attributes will apply regardless of which source the browser chooses!
The picture element is a container which provides multiple sources to its contained img element to allow authors to declaratively control or give hints to the user agent about which image resource to use, based on the screen pixel density, viewport size, image format, and other factors. It represents its children.
This could also conceivably be used for user tracking purposes as a way to determine without javascript the user's browser window setting. (I assume CSS can do this too.)