I found quite a lot of AVIF encoders lied about their lossless encoding modes, and instead used the normal lossy mode at a very high quality setting. I eventually found one that did true lossless and I don’t think it ever managed to produce a file smaller than the input.
Turns out, that’s a well known issue with the format. It’s just another case where Google’s marketing makes AVIF out to be fantastic, but in reality it’s actually quite mediocre.
The funny thing is, I knew something was off because Windows was generating correct thumbnails for the output files, and at that time the OS provided thumbnailer was incapable of generating correct thumbnails for anything but the simplest baseline files.
(Might be better now, idk, not running Windows now)
That’s how I knew the last encoder was producing something different, even before checking the output file size, the thumbnail was bogus.
This story is a nightmare and I’m not sure if it’s better or worse now knowing that it was ancient ICO files that tipped you off.
Open question to you or the world: for every lossless compression I ever perform, is the only way to verify lossless compression to generate before and after bitmaps or XCFs and that unless the before-bitmap and after-bitmap are identical files, then lossy compression has occurred?
jxl is a much better format, for a multitude of reasons beyond the article, but it doesn’t have much adoption yet. On the chromium team (the most important platform, unfortunately), someone seems to be actively power tripping and blocking it
PNG is the wrong approach for lossless web images. The correct answer is WebP: https://siipo.la/blog/whats-the-best-lossless-image-format-comparing-png-webp-avif-and-jpeg-xl
I found quite a lot of AVIF encoders lied about their lossless encoding modes, and instead used the normal lossy mode at a very high quality setting. I eventually found one that did true lossless and I don’t think it ever managed to produce a file smaller than the input.
Turns out, that’s a well known issue with the format. It’s just another case where Google’s marketing makes AVIF out to be fantastic, but in reality it’s actually quite mediocre.
They lied about the lossiness?! I can’t begin to exclaim loudly enough about how anxious this makes me.
The funny thing is, I knew something was off because Windows was generating correct thumbnails for the output files, and at that time the OS provided thumbnailer was incapable of generating correct thumbnails for anything but the simplest baseline files.
(Might be better now, idk, not running Windows now)
That’s how I knew the last encoder was producing something different, even before checking the output file size, the thumbnail was bogus.
This story is a nightmare and I’m not sure if it’s better or worse now knowing that it was ancient ICO files that tipped you off.
Open question to you or the world: for every lossless compression I ever perform, is the only way to verify lossless compression to generate before and after bitmaps or XCFs and that unless the before-bitmap and after-bitmap are identical files, then lossy compression has occurred?
jxl is a much better format, for a multitude of reasons beyond the article, but it doesn’t have much adoption yet. On the chromium team (the most important platform, unfortunately), someone seems to be actively power tripping and blocking it
Yeah Google is trying to keep control of their image format and they are abusing their monopoly to do so