Hacker News Reader

Comment by edflsafoiewq | Hacker News Reader

Does the difference matter?

Yes, if you look at the demo, the "progressive" AVIF loads a visible image at 8.5KB, and at that point, it looks better than the progressive JXL. However, that is ALL the AVIF shows until the image has fully loaded. At around 98KB, the JXL looks significantly better, and at around 240KB already looks really close to the final image, while the AVIF still looks terrible. At 280KB when the AVIF finally loads, they look identical.

BTW, you can configure the AVIF encoder to have another in-between pass or two so the quality jump isn't as big. The JXL folks just happened to go with only two total passes.

Won't that increase the total size of the image for each pass?

Thanks to AV1's inter encoding, overhead is overall minimal as each pass can refine on previous ones. Think of it as a mini-video. Because of this, in the case of images with a lot of repeated patterns, progressive AVIF encoding can actually result in more efficient images!

Looking at the demo linked in the blog post, I can make a similar quality thumbnail for a smaller size than the delta between the static and progressive AVIFs

The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.

Which sounds very useful if your connection is slow enough to make use of progressive image decoding. (Often enough the case for me.)

I prefer the UX of the AVIF example here. I think it's better to have a progressive phase where the image is obviously "not ready", yet you can still determine important details like the subject of the image (unlike a blurhash), rather than a phase that you could mistake for complete, but looks bad in parts.

Progressive rendering is just a different way to layout the pixel data. Embedding a thumbnail is storing two distinct images. In other words, progressive rendering should be more efficient space and bandwidth-wise.

The DC coefficients in a progressive JPEG are literally an embedded thumbnail (a 1:64 copy of the original) right? Is the question if the second "layer" replaces the thumbnail or layers corrections on top of it? It wasn't clear to me which AVIF does.

According to this source [1], a second layer can progressively provide the rest of the image data:

> Note: AVIF supports two types of progressive decoding. Spatial scalability can be used to offer a lower resolution image for network constrained users and 'progressively' provide a higher resolution image by sending just the additional data required to fill in the high frequency details. Quality scalability offers a similar progression by steadily improving visual quality with each render.

That is totally not what I expected. Though it's not clear to me how exactly you achieve it.

[1]: https://web.dev/articles/compress-images-avif

AFAICT progressive AVIF is actually using the "spatial layers" feature of AV1, which was designed to embed multiple resolutions of a video in one bitstream. The limit on four spatial layers comes directly from AV1. The previously decoded layer/progressive-step becomes a reference frame that the next layer can draw from just like eg the temporally-previous frame can be referenced by interprediction.

Of course it does, with one you have to render twice and store two layers which costs you both compute and storage. With the other you can just take the image mid decode at a point and display it. Single decode operation, no layer mess.

You have to render twice and have 2 different layers in both scenarios. Writing to a buffer / layer is not an atomic operation so they need to be separated.

The difference matters, as it means that AVIF's "progressive decoding" serves no technical benefit and is only a minor ergonomic benefit: On a website, you could achieve the same effect simply by layering two <img> elements on top of each other, one with the thumbnail and one with the final image.

If layering to <img> elements is fine for your use case, then it simply means you have no need for progressive decoding.

Reply on news.ycombinator.com