Support AVIF format

[Maxou44]

Hello :)

First of all, I'd like to thank you for this awesome open source project, it's amazing!

In August 2020, Chrome will be able to show AVIF images.

Source: https://chromium-review.googlesource.com/c/chromium/src/+/2276542

Because libvips already support AVIF format, it could be nice to add this format in weserv project, what do you think?

Have a great day, Maxime

[andrieslouw]

Will need to check this, thanks for the heads-up!

[kleisauke]

Reading 8-bit AVIF images should already work, see for example: https://images.weserv.nl/?url=http://download.opencontent.netflix.com.s3.amazonaws.com/AV1/Chimera/AVIF/Chimera-AV1-8bit-1920x1080-6736kbps-100.avif&output=jpg

However, some AVIF images (with the ftypavif magic bytes) cannot be decoded properly. This requires PR https://github.com/libvips/libvips/pull/1657, which is available in libvips 8.10 (to be released soon).

Writing AVIF images requires some research on our side to see if our servers can handle that. It also requires some minor adjustments to the codebase.

[Maxou44]

Firefox Nightly supports AVIF ☺️

[andrieslouw]

We started some work on this, but it is really beta, and AVIF-encoding will be an uphill battle (consuming lots of resources). We will notify you here if we start testing on images.weserv.nl, for now you can experiment using our code, the support is there as per ac3e355f90694d5e5c07ca05199bec7ead9a5eee .

[Maxou44]

It works well, I didn't found a bug on hundreds of images 😍 Really awesome 😎

[mehulmpt]

Thanks for adding support for avif! Any expected timeline by when it could be used on the main images.weserv domain?

[kleisauke]

AVIF decoding should already be supported (live demo). Unfortunately, AVIF encoding is slow and consumes a lot of resources even when rav1e is used, which is why we disabled it in the &output parameter. You might consider using our code to set up your own solution for full AVIF support.

Note that we are considering supporting JPEG-XL, as it is a good competitor to AVIF. However, it is not currently supported within the modern web browsers by default: https://caniuse.com/jpegxl.

[FinnRG]

@kleisauke Apple just announced that they will add JPEG-XL support in the upcoming Safari 17 release (source). It's likely that this will motivate the other browser vendors to improve their implementations as well. Are there any updates regarding JPEG-XL support for wsrv.nl?

[charsleysa]

@kleisauke now that all major browsers support AVIF and it's considered a Baseline 2024 feature, is there any chance of having it supported as an output?

The bandwidth savings compared to JPEG can be quite significant. Using https://squoosh.app, anecdotally I've found a ~20% file size reduction comparing JPEG @ 75 quality vs AVIF @ 75 quality 0 effort and a ~32% file reduction with AVIF @ 75 quality 2 effort.

[kleisauke]

@FinnRG JPEG XL support is blocked on https://github.com/libjxl/libjxl/issues/1450 and https://github.com/libvips/libvips/issues/3132. Furthermore, I would also like to see this being fuzzed in libvips' OSS-Fuzz integration before we enable it on our servers (see commit https://github.com/google/oss-fuzz/commit/890953f0a0029ef889c8c866c674bb8609f90bd0 for details).

@charsleysa Comment https://github.com/weserv/images/issues/238#issuecomment-974857730 is still relevant today, see e.g. issue https://github.com/libvips/libvips/issues/2983.

[degarb]

avif = free, non patented, supported by all browsers, doesn't reduce color variation like webp, smaller image size, and it's the only jpg improvement alternative (supported by all browsers) as reality now as of the spring 2024

I have been using weserv for weather images over my cell network to save data, time, and battery--typically using webp, which can dramatically reduce the size, so long as I am willing to accept minor image degradation, which usually doesn't affect the information in the weather image.

However, there are 1 or more weather images, where I need as many colors as possible to see if the rain is spitting rain or light rain, and webp doesn't cut it because it shows one blue color rather than two subtle shade differences.

I see that webp also reduces warm colors a whole lot on this comparison site: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_01_11/index.html#vallee-de-colca*1:1&Original=s&WEBP2=s&subset1

Now, I revisit this page every few years to see what is new, and do a little research.

This year, I learned that all webbrowsers, including mobile, this spring of 2024, now support AVIF!!! Static images only, for now. So....there should be no more reason to use webp for my weather images, since avif is now a reality; it doesn't reduce color variations like webp; and it should be a little smaller than webp.

The other tip off that google photos might convert over to avif, is they killed webp2 and demoted the code to something geeks can play with. ....

I would also note that avif is a reality, like webp, while jpg2, jpeg2000 and bpg have been talked about for decades and never went anywhere.

I see some reference to avif in the weserv code, but don't have the time to learn the language or analyze what I am looking at.

The downside to avif would be speed, which may not be an issue on modern machines, or even phone hardware. Also, whether request the parameter output=webp or output=avif in a shortcut on the android on the home screen, or embedded in a webpage, is a matter of choice, based on empiracal speed/size testing and preferences--so, the speed argument shouldn't be an issue. If the avif were too intensive on the system serving the image, the obvious workaround would be cpu throttling, or size limits.

I haven't fully investigated weserv and avif, yet. I tried to use my imagick php to convert a 40kb gif to avif, but only could get the size down to 15 kb (I don't remember if I resized the image), while the webp version is 6kb that I usually look at. I suspect that the avif is not really a real avif, but just the resized gif with an avif extension, since I would think I could get the file size down to the webp size by lowering the &q= parameter, but I couldn't.

jpg2 on that comparison page didn't look any better anything, but I assume the advantage is backward compatibility and speed. My bet is that google is lookin at the hardware technology improvements, and will try to adopt avif, or improve on it, to replace the aging webp format it using to archive all our home photos in the cloud. A small reduction in size is huge to google who is hosting the planets' photos, practically speaking.

avif = free, non patented, supported by all browsers, doesn't reduce color variation like webp, smaller image size, and it's the only jpg improvement alternative (supported by all browsers) as reality now as of the spring 2024