Experimenting with AVIF

Hi everybody,
Intrigued by the new ability to export AVIF, I’ve been playing around and building some data that I thought some others might be interested in. After my first export seemed to take forever, I decided to take a look at what options might be available for speeding up the encoding process (initially, I just wanted to see how much library choice mattered, and ended up going down this rabbit hole :grinning: ).

The hardware setup:
Dell inspirion laptop
Intel Core i5 4210U

The software setup:
OS: Kubuntu 19.10
Kernel: 5.3.0-42generic
CPU governor: performance
Energy governor: performance

darktable-cli 3.1.0+816~g396bf2aec-dirty

Libavif – v0.6.2-1-g56ffea3
AOM – v1.0.0-errata1-avif-404-g01c7a6602
RAV1E – p2020026-63-gde515e0
DAV1D – v0.6.0-12-g3f18519

Test file: 6032 X 4032 14-bit lossless compressed NEF from a Nikon D750

Method: I built two versions of libavif one with AOM and DAV1D, the other with RAV1E and DAV1D, swapping between them as necessary. Used “/usr/bin/time --format=‘Encode took %E’ darktable-cli test.nef output.xxx” for time and filesize testing. Modified speed variable in avif.c accordingly to see if there was any difference there.

Test 1: 8-bit Lossless encoding time and filesize (AOM vs RAV1E)

8 - bit lossless encoding chart
8 - bit lossless size with speed change

AVIF_SPEED_FASTEST seems to have huge implications on encoding time. Currently, AOM is consistently faster at the coded default of SLOWEST+1 and FASTEST (AOM @ FAST was overall winner), yet gets crushed at DEFAULT; making me think that AOM’s DEFAULT is set to pure SLOWEST while RAV1E uses a more middle value (I think the scale is 1-10 if I remember). Filesize differentiation is a little odd with RAV1E, I thought using faster speeds should produce larger files, as was the case with AOM.

Test 2: 8-bit Lossy encoding time and filesize (AOM vs RAV1E) default compresson (91%)

8 bit lossy time chart
8 - bit lossy filesize chart

Using lossy AOM is quicker at the coded default, but RAV1E is quicker set to DEFAULT and FASTEST (RAV1E @ FAST was overall winner). Weird filesize anomaly with AOM set to FASTEST, it was repeatable and doesn’t show errors importing back into dt however.

Test 3: Lossless 8,10,12-bit filesize difference RAV1E

Rav1e 8,10,12 bit filesize

This was kind of interesting in that I would expect the largest file to be from the FASTEST setting but the opposite was true. I couldn’t get AOM to complete an export at 10 or 12 bit (it would get killed with a signal 9, unless I cropped the test file smaller), I think this was due to it’s brute force use of resources. It seems like AOM will use all available memory even filling swap when trying 10 or 12-bit. As a result, encoding with AOM may make your machine VERY unresponsive until the encode finishes. RAV1E seems to work much more nicely, behaving much like the other export formats:

Test 4: Comparison vs some common formats

Encoding time all chart
Filesize all chart
Narrow margins vs scale of graph makes it a bit hard to judge so here’s the actual results:
List of all

The overall speed winner was jpeg @ 19.9s, overall filesize went to Lossy RAV1E @ 6.2MB. Interestingly, lossless avif seems to be smaller than the lossless png and tiff formats.

Hopefully this data can help anyone else interested in checking out this new file format.

1 Like

32:21.28 means 32 minutes 21 seconds ???

That’s concerning. Is the lib single-threaded and not vectorized ?

Minutes and seconds, yeah! I was surprised as well. You can see my initial interest in looking at what could cut that time down came from. Both libs seem to trigger all 4 cpu threads, not sure about vectorization. I haven’t really dove into each implementation quite yet. I expect things will get better as they become more and more optimized.

Lossy size is not extremely meaningful without relating it to image quality. How does it fare on that front?

Excellent question! I’d say it seems to be quite competitive, not sure if it will translate well through screenshots, but here’s a side by side snapshot at 2:1 zoom in darkroom module.

jpeg @ 95 quality on left (6.7MB) and lossy AVIF using RAV1E @ 95 quality on right (4.9MB):

and at 1:1 :

The avif is quite comparable, it’s difficult to see much of a difference.

There’s a new pure Rust based AVIF converter / encoder that runs on all cores. It also has no memory issues with large images.

1 Like