Add AVIF support to resize_image() #1347
Conversation
|
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. |
|
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. |
|
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 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. |
|
Hi! I was going through this pull request and thought I could perhaps locally merge it with the latest commit to have I noticed that zola/components/imageproc/src/lib.rs Lines 19 to 22 in 2fff0c2 zola/components/imageproc/src/lib.rs Lines 19 to 22 in fc808f2 |
|
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 |
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 |
|
Oh it's probably just a merge issue. Webp is still supported |
Keats
force-pushed
the
next
branch
2 times, most recently
from
1e55db1
to
3155662
Compare
|
Ubuntu 22.04 is out now, does this resolve the previous version issue? AVIF is really nice! |
|
Following on from #1347 (comment) Ubuntu 24.04 is out now, containing |
|
How about Windows? I've seen some issues on other crates with nasm there |
Keats
force-pushed
the
next
branch
2 times, most recently
from
8b1a413
to
67c2fe0
Compare
|
I would like to check if this works ok on Windows now so that it can be merged. I will try building Zola on Windows today. |
|
Since I opened this pull request, things have moved on somewhat in the image codec space. Chrome are dragging their heals adding jpeg-xl support, but even then I'm not sure avif is necessarily worth adding to Zola. Quite a few tests are now showing that, while it has a good file size to quality ratio, the encode and decode speeds are exponentially slower than other formats; possibly outweighing any gain in transfer size on low powered devices. I'll put a few links at the bottom of this comment for others to read through, but it really looks like that, in real world scenarios, good old fashioned image codecs such as jepg (and now jpeg-xl) actually work better than those newer ones based upon video codecs, such as webp and avif. Google's benchmarks for webp, and possibly to a lesser extent the recent ones for avif, do seem to be based on carefully cherry picked datasets and competing encoders to show the new codecs in the best light. There was a brilliant article graphing the filesize vs ssim quality for various formats that showed jpeg-xl as the clear winner for all but the smallest of images, but I can't seem to find it. |
|
Avif and for that matter AV1 are still relatively new, but AVIF does have excellent browser support now: https://caniuse.com/?search=avif JXL is seemingly only supported on Safari... https://caniuse.com/?search=jxl When I searched about when jxl was created I found December 2019, for whatever reason nobody seems to want to adopt it, not only Chrome. I also found an article that makes jpeg xl look good, but with it being unsupported in browsers I will probably just stick with avif for now: https://tonisagrista.com/blog/2023/jpegxl-vs-avif/ Thanks for the info and the links, I honestly did not even know jpegxl existed. EDIT: He actually made a blog article about why jpegxl is not supported as well: https://tonisagrista.com/blog/2022/jpeg-xl-chrome/ |
|
I tried to rebase this pull request on the current next branch of Zola but a lot has changed with Zola since then and I do not yet know Rust or Zola well enough to bring this pull request up to date. |
|
I think Chrome might not have a choice if iPhones start to shoot in JXL |
|
I am attempting to figure out the issues with rebasing this pull request. I have resolved some of the errors and think I am close. EDIT: got it to compile, now I just need to make sure it actually works! |
The build on Windows had Zero issues (click to expand):
I could really use some help testing this to make sure I did not mess anything up. If I had to guess I would say I have less than 48 hours of actually working with Rust, I have read the rust book twice but have not actually used rust much. |
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:
Code changes
(Delete or ignore this section for documentation changes)
nextbranch?If the change is a new feature or adding to/changing an existing one:
This pr adds support for AVIF images to the
resize_image()function, closing #1202. Asimagedoes not currently allow setting the speed and quality parameters via thewrite_to()method this manually creates an encoder and writes the result out to a file.There are 2 caveats to this implementation:
speedparameter is hardcoded. This currently uses the same default as thecavif-rscrate (whichimageuses 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 toresize_image()as I felt it would start to get unwieldy. Perhaps eventually this could be overriden inconfig.toml?