Dude... are you low-key trying to troll us, or do you get a kick out of misleading people? How can you manage to be confidently wrong this much? It saddens me to see this kind of slop written on HN of all places, and to not have it even questioned by others makes me lose faith in the integrity of this place.
Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts.
> especially AVIF that can't really do lossless RGB
AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC).
> webp ungodly smoothing
There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking.
> libaom is a reference codec thus slow
libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues.
> and not really interested in proper psy optimizations
libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3].
> SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it
No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios.
Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used.
> Progressive decoding
AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away!
The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :)
Bad formulation, the bit that followed those words does detail the "not really" part: compression just takes a massive hit compared to YUV; at least when I tried it last time with libaom (https://news.ycombinator.com/item?id=48359211)
> There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing
Now you're the one being funny. libvpx is famous for its strong PSNR tuning thus preference of blurring over blocking. Even libaom has the same problem.
> libaom (the production encoder) isn’t slow at all, especially for image encoding
Well, that's true that for image encoding, it's alright in performance. Last time I checked, lossless encoding was still way too slow with a decently strong preset (cf first link).
> libaom has psy optimizations
"Some". Since you're one of the people that worked on the psy features now upstreamed into SVT-AV1 (many thanks for that), you know much better than me how libaom has really nothing to match --tune 0.
My bad for using the word "port", but clearly a lot of them like the better aq-modes were conceptualized there.
> AVIF has had progressive encoding/decoding support for years.
Completely forgot that, thanks for the correction.
Maybe I was flaming a bit too much and maybe you're strongly involved in the AV1 world, but "trolling" is a bit much. I followed AVIF since libavif was started by Joe Drago and was really interested in the idea of using a video format's I-frame format to get hwdec/dav1d "for free" and the potential gains from grain synthesis, but the AV1 ecosystem having been so focused on VoD/PSNR and only now starting to be viable for transparency, the lossless/grayscale story being what it is has somewhat made a JXL champion out of me.
Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts.
> especially AVIF that can't really do lossless RGB
AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC).
> webp ungodly smoothing
There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking.
> libaom is a reference codec thus slow
libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues.
> and not really interested in proper psy optimizations
libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3].
> SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it
No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios.
Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used.
> Progressive decoding
AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away!
The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :)
[1] https://halide.cx/iris/ [2] https://aomedia.googlesource.com/aom/+/refs/heads/av1-normat... [3] https://halide.cx/blog/improving-avif-in-open-source/ [4] https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-... [5] https://jpegxl.info/resources/progressive-loading-demo.html