4 ms·

> Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a wh

> Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over. This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail. Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.

edflsafoiewq 19d ago
Does the difference matter?
- aniviacat 19d ago
  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.
- cpburns2009 19d ago
  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.
  - edflsafoiewq 19d ago
    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.
    - cpburns2009 18d ago
      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 https://web.dev/articles/compress-images-avif
      - edflsafoiewq 18d ago
        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.
- oofdere 19d ago
  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.
  - F3nd0 19d ago
    Which sounds very useful if your connection is slow enough to make use of progressive image decoding. (Often enough the case for me.)
  - juliobbv 19d ago
    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.
    - oofdere 19d ago
      Won't that increase the total size of the image for each pass?
      - juliobbv 19d ago
        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!
        oofdere 19d ago
        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
- tacomagick 19d ago
  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.
  - charcircuit 19d ago
    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.
computerbuster 19d ago
Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.
MiroslavPokorny 19d ago
How does progressive rendering actually that most OS GUIS are not multithreaded ? The preview in finder is still going to block. Im saying this as a MAC user speaking of experience browsing mounted drives that sometimes are slow and it feels like the window freezes up.
- wmf 19d ago
  Progressive rendering is intended for the Web and it does work.
- brigade 19d ago
  Thumbnailing happens in a background process and shouldn’t block the main thread; rather hangs are usually because fetching xattr over SMB is slow and Finder will block until it’s enumerated the metadata of every file in a folder. Preview actually does use progressive rendering for large enough images, even from SSDs. You can tell because opening an image will be blurry for several seconds, even when the full size image could have been decoded in a quarter second or less.
brigade 19d ago
You're wrong. AVIF does support spatial layering where the full-resolution image is derived from the lower-resolution layer, and cannot be decoded independently. Yes, the format is not inherently progressive. But having the fine steps in progressive quality that JPEG-2000 and JPEG-XL have has less general usefulness than the amount of words complaining about it.
- F3nd0 19d ago
  Can a similar technique be employed in JPEG XL, or does the format not allow for it in any way?
- lgkrnkglwn 19d ago
  Jpeg2000 (and jpeg ls and jpeg xr) thankfully wasn’t implemented in any major way. Keep it simple, stupid.
derf_ 19d ago
> A lower resolution image layered below the full resolution image, which is loaded and rendered first. Unlike a thumbnail, higher-resolution layers can be predicted from the lower-resolution layer, so those bits are not wasted. That is not possible by layering <img> elements.
juliobbv 19d ago
> A lower resolution image layered below the full resolution image, which is loaded and rendered first. 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.
- deleted 18d ago
  [deleted]

edflsafoiewq 19d ago

Does the difference matter?

aniviacat 19d ago
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.
cpburns2009 19d ago
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.
- edflsafoiewq 19d ago
  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.
  - cpburns2009 18d ago
    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 https://web.dev/articles/compress-images-avif
    - edflsafoiewq 18d ago
      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.
oofdere 19d ago
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.
- F3nd0 19d ago
  Which sounds very useful if your connection is slow enough to make use of progressive image decoding. (Often enough the case for me.)
- juliobbv 19d ago
  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.
  - oofdere 19d ago
    Won't that increase the total size of the image for each pass?
    - juliobbv 19d ago
      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!
      - oofdere 19d ago
        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
tacomagick 19d ago
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.
- charcircuit 19d ago
  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.

computerbuster 19d ago

Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.

MiroslavPokorny 19d ago

How does progressive rendering actually that most OS GUIS are not multithreaded ? The preview in finder is still going to block. Im saying this as a MAC user speaking of experience browsing mounted drives that sometimes are slow and it feels like the window freezes up.

wmf 19d ago
Progressive rendering is intended for the Web and it does work.
brigade 19d ago
Thumbnailing happens in a background process and shouldn’t block the main thread; rather hangs are usually because fetching xattr over SMB is slow and Finder will block until it’s enumerated the metadata of every file in a folder. Preview actually does use progressive rendering for large enough images, even from SSDs. You can tell because opening an image will be blurry for several seconds, even when the full size image could have been decoded in a quarter second or less.

brigade 19d ago

You're wrong. AVIF does support spatial layering where the full-resolution image is derived from the lower-resolution layer, and cannot be decoded independently. Yes, the format is not inherently progressive. But having the fine steps in progressive quality that JPEG-2000 and JPEG-XL have has less general usefulness than the amount of words complaining about it.

F3nd0 19d ago
Can a similar technique be employed in JPEG XL, or does the format not allow for it in any way?
lgkrnkglwn 19d ago
Jpeg2000 (and jpeg ls and jpeg xr) thankfully wasn’t implemented in any major way. Keep it simple, stupid.

derf_ 19d ago

> A lower resolution image layered below the full resolution image, which is loaded and rendered first. Unlike a thumbnail, higher-resolution layers can be predicted from the lower-resolution layer, so those bits are not wasted. That is not possible by layering <img> elements.

juliobbv 19d ago

> A lower resolution image layered below the full resolution image, which is loaded and rendered first. 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.

deleted 18d ago
[deleted]