Official C encoding/decoding library: https://github.com/AOMediaCodec/libavif
It does not seem to offer any advantages that I can see
I tested a 521mm x 346mm translucent png = 437 KB (1969 x 1307 x 32bit)
Using the encoder linked to above I waited wasted 6 minutes of my life until it was encoded to a phenomenal 1,206,685 bytes thats over 2 1/2 times the storage and I have no idea how long it takes to decode as I am not going to bother using that one.
In fairness according to Netflix that image should have been heavily encoded to about 1/3 the size. But then none of their samples, I tested, could be opened by my up to date MSpaint which is supposed to support them.
I tried webp (new kid on the block about 10 years ago) which for the same file is only 290 kB and SumatraPDF displays it in under 2 seconds. So it's a very good contender for .cbz format see here I have renamed the zip to cbz

Every so often we see problems with users complaining SumatraPDF is "slow" to decode this or that file. The file when tested is either stupidly large and/or heavily compressed. A Reading page of colour print needs at most 150 dpi (* see footnote). It only needs to be a higher resolution if its intended use is for bank notes or high quality glossy photo printing.
So the above png page size is efficient, quick to decode, simple and very easily produced / printed / converted to other formats.
A zip folder full of png files is perfect for comic book or similar non typography publishing hence .CBZ
Once the technology is tried, tested, and we all have 16 thread processors for decompression then it might be worth adding.
Thanks for the quick response. Just to give some context, I mainly use WebP format to store scanned documents, comic books, etc. As an example, I usually reconvert comic books (CBZ with JPGs) and I end up with 50-60% of the original file size with no noticeable visual issues.
I haven't tested AVIF enough, just a few samples using go-avif, which is a bit dated, and with the default quality setting it did give me smaller sizes than my preferred setting for encoding WebPs, with comparable visual quality. I was able to open the encoded files with the latest XViewMP, and with MSPaint (after installing the AV1 Video Extension from Microsoft Store).
But again, I haven't tested enough and I do agree that the encoding process is far slower.
As long as the AV1 extension's installed Paint can display AVIF files just fine, even on older Win10 versions (I just tested with both 1909 and 1809).
Given that AOMedia has Amazon, Apple, ARM, Cisco, Facebook, Google, IBM, Intel, Microsoft, Mozilla, Netflix, Nvidia, Samsung, Tencent etc. throwing their weight behind AV1, this definitely seems to be the future in terms of video at least. Frankly I'd say even the image format AVIF has a much better shot at popularity than WebP, but whether it makes sense to add support for it now to Sumatra is for kjk to decide.
To set expectations: I'll probably add .avif support, because it's probably not hard.
At the same time, it has a low priority now because it's not yet a widely used format.
你好!很喜欢你的程序,不知道能不能添加"添加标签的功能"?
Hello! Very like your program, I do not know if you can add "add the function of the label" ?
@Lw960201
This topic is for AVIF still image file format , It is not clear why AVIF image needs labels
AVIF video may support subtitling
However, zip folder images are normally just identified / tagged by the changing filenames.
@jfveronelli
With the .vbkm format (virtual pdf) we could edit all image names if we want to
As you know all cbx images in general look like this

there it is down to the compositor to label the filenames for each image and its containing archive folder the additional use of archive comments or ASDF data & even including x(ht)ml indexes have all had their own problems.
With Sumatrapdf .(v)bkm support we can already call them what we like

However, especially zip files it is potentially so much simpler / universally acceptable to just open the zip and simply rename the file contents. No need for extra files or risk of lost steam data
@kjk: Just a small note with regards to the thread title - Shouldn't it simply be, "Add AVIF support"? Comic book files need not be mentioned because just like with other formats like JPG or WEBP, AVIF images too should be supported either when opened directly or no matter the container format - be they embedded within ebooks, PDFs, CBx files etc.
Let's not overthink things. I just don't like "Feature request" in the title, because it's redundant.
I couldn't care less whether there's a "Feature request" in the title or not, so I don't understand where the overthinking part came in? I just wanted to say that "Add AVIF support _to comic book files_" makes it seem like the support will be specific to the CBx format only, whereas obviously the support should be for the app as a whole regardless of format, that's all.
Most helpful comment
To set expectations: I'll probably add .avif support, because it's probably not hard.
At the same time, it has a low priority now because it's not yet a widely used format.