Add AVIF support to resize_image()

[BezPowell]

IMPORTANT: Please do not create a Pull Request adding a new feature without discussing it first.

The place to discuss new features is the forum: https://zola.discourse.group/
If you want to add a new feature, please open a thread there first in the feature requests section.

Sanity check:

• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Code changes

(Delete or ignore this section for documentation changes)

• Are you doing the PR on the next branch?

If the change is a new feature or adding to/changing an existing one:

• Have you created/updated the relevant documentation page(s)?

---

This pr adds support for AVIF images to the resize_image() function, closing #1202. As image does not currently allow setting the speed and quality parameters via the write_to() method this manually creates an encoder and writes the result out to a file.

There are 2 caveats to this implementation:

1. The speed parameter is hardcoded. This currently uses the same default as the cavif-rs crate (which image uses for avif encoding). This encoding speed can be very slow, so it might be nice to allow changing this. I did not add it as another argument to resize_image() as I felt it would start to get unwieldy. Perhaps eventually this could be overriden in config.toml?
2. AVIFs quality levels, while accepting the same range as jpeg are very different. The default value of 75 actually results in a file slighty bigger than the equivalent jpeg. I do not know how AVIF SSIM values compare to jpeg for different quality settings, but it might be nice to choose a different default for AVIF that has a similar SSIM to jpegs 75 quality level.

[BezPowell]

Apologies for the duplicate PRs. Looks like when I first created my avif branch I accidentally based it on master, rather than new. Should all be clean now hopefully.

[BezPowell]

I have been doing some tests on quality vs filesize for AVIF files, and it looks like somewhere in the region of quality 50 would be a more sensible default value for AVIF to roughly correlate to jpeg at 75. I could not get any SSIM analysis tools to work on my machine with AVIF, or losslessly convert my generated AVIF files to something like png, so this comparison was done by eyeballing images and is rather unscientific.

If someone else can manage to get a proper test setup sorted, I would be very interested to know what their thoughts are regarding a sensible default quality level. I don't think we should have the same default level for jpeg and avif as the scales really are not comparable and could put people off using the new format (as AVIF at 75 is often bigger than even baseline jpeg, though of course higher quality), but would be interested to hear other people's thoughts on the matter.

Another interesting side effect of my tests was me realising just how good mozjpeg is at retaining quality at smaller filesizes while still retaining good compression speed. AVIF does seem to outperform it in terms of quality vs filesize, but takes much longer to compress.

[Keats]

It looks like it doesn't compile on any of the platforms we support due to the nasm version required though...

[BezPowell]

It looks like it doesn't compile on any of the platforms we support due to the nasm version required though...

That's a bit of a pain. I'm working on Fedora here, so didn't notice as they usually ship pretty up to date versions of packages. Shall we have to shelve this one for now then?
I'm not sure what Ubuntu's policy is for individual package updates, but that could mean waiting for the next LTS?

[Keats]

I think it would be better to wait a bit yes, even mac and windows are failing on CI which means most users will encounter the same issue when building from source.

[imjasonmiller]

Hi!

I was going through this pull request and thought I could perhaps locally merge it with the latest commit to have .webp and .avif support ― considering GitHub's CI seems to support Ubuntu 20.04 Focal Fossa, which meets nasm >= 2.14.02 per this comment.

I noticed that RESIZED_FILENAME does not contain avif in this pull request, but webp does. Is this supposed to be the case?

zola/components/imageproc/src/lib.rs

Lines 19 to 22 in 2fff0c2

	lazy_static! {
	pub static ref RESIZED_FILENAME: Regex =
	Regex::new(r#"([0-9a-f]{16})([0-9a-f]{2})[.](jpg|png)"#).unwrap();
	}

zola/components/imageproc/src/lib.rs

Lines 19 to 22 in fc808f2

	lazy_static! {
	pub static ref RESIZED_FILENAME: Regex =
	Regex::new(r#"([0-9a-f]{16})([0-9a-f]{2})[.](jpg|png|webp)"#).unwrap();
	}

[Keats]

We need easy support on all 3 platforms. If it can be disabled as per the issue then we could enable it on linux if it's nasm is common enough. Zola is already hard enough to build because of libsass, let's not add more roadblocks

[imjasonmiller]

We need easy support on all 3 platforms. If it can be disabled as per the issue then we could enable it on linux if it's nasm is common enough. Zola is already hard enough to build because of libsass, let's not add more roadblocks

Oh, no, I wasn't implying that @Keats, as that seems troublesome. I was looking into getting it to work locally for that reason.

I noticed webp was added to RESIZED_FILENAME for the next branch, but avif in this case was not? I thought I'd ask if that was intentional.

[Keats]

Oh it's probably just a merge issue. Webp is still supported

[Jieiku]

Ubuntu 22.04 is out now, does this resolve the previous version issue?

AVIF is really nice!