Current state of AVIF

[Pentium4User]

Hello!

At least one website that I visit regularly wants to use the AVIF image format.
There already has been discussion about it in Pale Moon: viewtopic.php?t=29604

Is there anything new about that topic?

kind regards
p4u

[Moonchild]

viewtopic.php?t=29604#p237907 still applies. Especially with jpeg-xl being a thing now, AVIF really adds nothing of value.

[tristan9]

Especially with jpeg-xl being a thing now, AVIF really adds nothing of value.

JXL is better and by far, but until the morons in the Chrome team change their mind, it is unfortunately fucked.
You can serve it, sure, but if you need an extra copy of all your images usable only by 20-30% of your userbase, you are going to need really deep pockets.

And do not misunderstand me, as the situation makes me as pissed as you, if not more.
We have on the order of 80 millions of historical JPEG files, and we stand to losslessly save on the order of 20 terabytes of storage on them, and that's usable storage so multiply by 5 to account for replication and backups (and petabytes of bandwidth alongside it). And losslessness is a requirement for us, so we absolutely need JXL specifically.
But it is what it is, and we need to be realistic in that no one is getting it until they change their mind. Sucky situation, but not the first or the last for the web platform as a whole...

That said, I'm fine with a stance being taken against AVIF, and I agree that it is not the format we all deserve to see succeed.
But let's not make a technical argument against it, as it is disingenuous in the same way as Chrome's rejection of JXL. Yes it is not as good as JXL, but it's still much more desirable than a WebP world...

[Moonchild]

Yes it is not as good as JXL, but it's still much more desirable than a WebP world...

WebP is supported by us too, and WebP supports lossless as well. AVIF does not add any value to the collection of image formats we already support. In fact, it's just a "let's do what webp does but with a different video still format". It is NOT worth the investment of time and effort for us to support this. We already lost plenty of time before with jxr/photohd. If people really want a genuinely better lossless, easy to implement, fast, web-focused format they should look at QOI bug #1765908 and not YAVIF (Yet Another Video Image Format)

If you start with jpeg you already have only a lossy source format, so what's your point, anyway?

[tristan9]

WebP is supported by us too, and WebP supports lossless as well. AVIF does not add any value to the collection of image formats we already support. In fact, it's just a "let's do what webp does but with a different video still format". It is NOT worth the investment of time and effort for us to support this. We already lost plenty of time before with jxr/photohd. If people really want a genuinely better lossless, easy to implement, fast, web-focused format they should look at QOI bug #1765908 and not YAVIF (Yet Another Video Image Format)

WebP is so much worse at lossless that it makes it essentially a useless format. And the tooling (libraries etc) is unbelievably bad at every single step of the way. Its only redeeming factor is being better than jpeg at visibly-compressed levels.

That said I fully agree on AVIF being not worth your time, as I said in my message in the first place. But it is still better than WebP for anyone that cares at least a bit about image quality.

If you start with jpeg you already have only a lossy source format, so what's your point, anyway?

A lossy input is okay as it is what is is provided by the user, and their will is what matter as it is their content.
Us applying extra loss on top of it is not.

Also jpeg is not just a lossy tradeoff for small images.
It is much worse at handling grayscale than some smart png handling for example, and rarely even a benefit in size for these unless you're willing to drop below q50.
But it is often very appropriate for colored content, when it is reducing a 60MB png file down to 15MB with no discernable loss in visuals (and I mean genuinely so, not the ambient undiagnosed-eye-deficiency level of "it's the same"). Mind you, that is knowledge we expect users to exercise, and we don't take the liberty of doing it for them.

Point is, jpeg has valid use cases even when you care about fidelity without needing strict (ie technical) losslessness..
And thus lossless handling of jpeg files is very relevant.

Also sometimes the input files are in fact barely-acceptably-artifact-ridden jpegs, and it's extremely desirable to not worsen the situation.
Therefore lossless jpeg handling again.

[Moonchild]

Sorry but if you care about conversion to a lossless format that much then you should just convert it to PNG which is supported by everyone and their uncle and (on average across various image categories) provides better compression than AVIF(!), especially if you hate the WebP tooling as much as I do. That way you only need to supply the original JPEG and a transcoded lossless PNG. If you have an issue with tooling writing out optimized PNG files then I could even help optimize them for you. I have some good tools for that.
Of note is that lossless compression to WebP and JPEG-XL is also considerably better than AVIF, so if bandwidth is your concern you really shouldn't be looking at AVIF at all!

Alternatively, you could set it up to transcode images on-the-fly instead of storing transcoded images.

If you want me to back this up with data, look at https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit?gid=174429822#gid=174429822

[tristan9]

Sorry but if you care about conversion to a lossless format that much then you should just convert it to PNG which is supported by everyone and their uncle and (on average across various image categories) provides better compression than AVIF(!), especially if you hate the WebP tooling as much as I do.

I was probably unclear. When we receive a jpeg file, we don't transcode it, only strip exif data and run through mozjpeg. My point was that we sometimes receive large (colored+drawing) jpegs, and they are the objective right choice for size while also being of very high quality, and converting those to PNG or lossless WebP is likely to multiply the size by 2 or 3, even with post-processing of the output png with the usual tools.
And for obvious reasons we can't risk automatically doing further non-lossless operations on them.
Of course sometimes it's also just a mistake, but that's hard to automatically handle with 0 false-positives ever. And we are unable to keep a close eye on it (we receive 15-20k new images per day minimum).

As for AVIF, it won't be a stored option for us for the foreseeable future anyway... But yes I probably hate WebP tooling as much as you do.

That way you only need to supply the original JPEG and a transcoded lossless PNG. If you have an issue with tooling writing out optimized PNG files then I could even help optimize them for you. I have some good tools for that.

We're well-aware of pingo and oxipng for lossless optimization, and we use the latter automatically (alongside stripping metadata) because pingo is a problem in a linux environment.
And also we know very well of reducing bit depth on grayscale pngs to get the most of our every byte without sacrificing quality (such as going to 4bpp as we don't consider scanner-induced-tones to be actual data). Though we never apply that transformation ourselves, merely suggest it to prospective uploaders when they try upload hilariously unoptimized files and hit our upload size limits.

Of note is that lossless compression to WebP and JPEG-XL is also considerably better than AVIF, so if bandwidth is your concern you really shouldn't be looking at AVIF at all!

Alternatively, you could set it up to transcode images on-the-fly instead of storing transcoded images.

I know, but alas:
1. JXL isn't widespread enough to prerender and justify the space
2. We are not even close to having the compute necessary for (non-shit) on-the-fly conversion... (we serve around 450 image cache misses per second, at an average of 92% cache hitrate)

That said I appreciate you sharing that detailed spreadsheet and will look at it closely!

[Moonchild]

Ultimately I don't understand what you want from us here. If you're dealing with high-volume image data then it doesn't matter what alternate format you want to use - even the best case scenarios aren't going to give you magical ratios on lossless that will make a significant dent in your storage or BW because that's just not how data compression works. You'll just have to get better storage and peering agreements if you're running into restrictions there.

You will have to choose the metric that matters most to you and choose based on that. If that is byte size then WebP is likely what you want (but it's slow in compressing) until JPEG-XL is more widely adopted (which actually just means telling Google to support it already - it will require SERIOUS evangelism because they have their own format they'd rather push, regardless of JXL being better in many ways). Asking us to adopt an additional inferior format just because anything AV1 is currently "trending" is just nonsense. AVIF is literally the worst option in the entire chart.

[tristan9]

> even the best case scenarios aren't going to give you magical ratios on lossless that will make a significant dent in your storage or BW because that's just not how data compression works

You're misunderstanding my message. What I want is also JXL. Because JXL allows me to save space/bandwidth losslessly on all these jpegs I cannot currently manipulate freely. With it I don't have to worry anymore at all, and can optimize all jpegs just like I can do all pngs. And sample tests show that on average I'd save 20-30% of the size after lossless transcoding to JXL. So yes the magic bullet exists, it's just not available right now for the reasons we all know (Google being shit).

My point was merely that we should be careful to not make the same type of arguments about AVIF that they're making about JXL. AVIF is much preferrable to WebP if only for tooling. And yields marginally better results on top of that.
Is it already worth investing into for PM? Probably not, that I agree on. But we need to be honest even if Google isn't.