I'm curious, where did you learn progressive AVIF works like this? Have you actually read the spec, or does your understanding comes from somewhere/someone else and never challenged the truthfulness of it? Progressive AVIF is truly "progressive" -- it never involves "loading a thumbnail" or "layering an image over another".

In reality, each pass (up to 4) can refine previous ones (thanks to AV1's inter-encoding toolset), avoiding storing redundant information between passes. The viewing environment doesn't need to render a given pass if a subsequent one has already been downloaded. Finally, scaling is configurable -- you can have your first pass already be at full res, just at a lower quality.

Hope this helps clarify how progressive AVIF actually works under the hood.

That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.

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

The default speed in libavif (-s 6 in avifenc) is fast enough, and it has been used by big CDNs to encode AVIFs for years. You can make the encoder as fast or slow as you'd like, depending on your compute/compression efficiency trade-off requirements.

I've been noticing people in this space react to these news in a very worrisome manner, either by downplaying the need of nsfw in their lives (ironically, hours after discussing a clearly-nsfw matter!), or even worse: by equating all nsfw to "porn"; giving them carte blanche to judge others who want the option for nsfw talk as "being in it just for sex".

It's been shocking for me to see this phenomenon unveil in real time. This overwhelming "sanitizing" force that bulldozes through any nuance regarding the nature of being an adult in shared online adult spaces. It's especially rough for marginalized or minority communities, who oftentimes don't even have IRL spaces to talk about adult subject matters.

BTW, this is no longer true. With the introduction of tune IQ (Image Quality) to libaom and SVT-AV1, AVIF can be competitive with (and oftentimes beat) JXL at the medium to high quality range (up to SSIMULACRA2 85). AVIF is also better than JPEG independently of the quality parameter.

JXL is still better for lossless and very-high quality lossy though (SSIMULACRA2 >90).

This Proof of Concept shows promising results: at 27 characters, AvifHash outperforms BlurHash https://blurha.sh/ (using 4x3 components) in quality and detail retention. At a similar quality, BlurHash needs 54 (5x5) to 76 characters (6x6 components).

Given that AVIF decoding is done by the web engine, AvifHash is very small: the entire demo page (including parsing and re-hydration code) is only 2.3 kB gzipped.

Comments URL: https://news.ycombinator.com/item?id=41513469

Points: 8

# Comments: 0

You can check if deltaq is being used in pictures, by opening the AVIFs in aomanalyzer (https://pengbins.github.io/aomanalyzer.io/), and in the Frame Info tab, check that the DeltaQ Res / Present Flag are set.

- `deltaq-mode=2` or `deltaq-mode=3` each enable different flavors of variance adaptive quantization, for a more consistent image quality

- `tune=ssim` enables the SSIM tune, which correlates better with subjective quality

In addition, if you're adventurous, you might want to switch to an alternative encoder that has further tuning for static images. Examples are https://gitlab.com/damian101/aom-psy101 (which notably has a fixed `sharpness` parameter that actually works beyond a value of 1), and most recently, https://svt-av1-psy.com/avif/ with the new "still tune" 4 that reliably beats aomenc in 4:2:0 chroma mode at medium effort speeds.