5 ms·

Isn't that kind of the point though? AV1/AVIF has an extremely strong case for hardware implementations: you need efficient (both in terms of processing and com

by Latty 2y ago

Isn't that kind of the point though? AV1/AVIF has an extremely strong case for hardware implementations: you need efficient (both in terms of processing and compression) video decoding on modern devices because the battery cost/bandwidth cost is so high otherwise. Image decoding is nice to have, but less important. When you are deciding to put custom hardware into a device, that's a huge investment in something only useful for that one task. Being compatible with a video format so you can share that hardware between the two tasks is a huge win for hardware manufacturers who get two-for-one, and for the rate of adoption. With AV1 already very efficient and rolled out in a lot of hardware already, it just has a huge advantage.

OuterVale 2y ago
While that most definitely is a consideration, AVIF lacks many features and much of the functionality offered by JPEG XL. An investment in JPEG XL, while only being beneficial for one task like you say, would have huge benefits given just how many images we see and process on the web. AVIF certainly gets the hardware support advantage, but it fails in other regards where JPEG XL shines. Looking at it either way, JPEG XL is far from slow, and I'd argue that the other benefits outweigh that single shortcoming. Bandwidth should also be treated as a consideration, as you mentioned, and JPEG XL generally leads to smaller file sizes. Realistically, this boils down to AVIF being largely worse than JPEG XL, with the exception of performance. Performance that could be improved for JPEG XL should hardware vendors choose to provide better support.
- Latty 2y ago
  Any features that matter to consumers more than slightly better battery life? I haven't seen one yet despite people always touting "better features". It feels to me like JPEG XL's advantages are mostly hypothetical, and practically AVIF is the format that has more value. I'm no expert on this, to be clear, but I have yet to be convinced despite all the JPEG XL hype on HN.
  - janwas 2y ago
    Disclosure: I worked on JPEG XL, opinions are my own. The radio(network) on phones can consume more power than the SoC(CPU). Thus smaller size can translate into energy savings. As to hypothetical advantage, we are talking about HW _potentially_ being used for image decode. AFAIK this does not happen in practice, despite WebP non-lossless being a VP8 frame and the hardware being plentifully available. As evidence for the advantages of JPEG XL being real, consider the fact that it is increasingly being adopted in serious SW including ACR, Darktable, Krita, and Lightroom.
    - Latty 2y ago
      JPEG XL is significantly smaller? All the stuff I've seen has show a slight edge for the same visual quality, but not enough I'd suspect it'd offset hardware decode, although if software doesn't actually do hardware decode, then yeah, the argument falls apart. I can 100% see JXL being adopted in production tools, where the motivations are different, I was mainly talking about the web adoption perspective for end users (which is the context of Google's supposed war on it, of course).
- unlord 2y ago
  > While that most definitely is a consideration, AVIF lacks many features and much of the functionality offered by JPEG XL. What features are these? You have not named a single concrete advantage. The places where AVIF out-performs JPEG XL are exactly where it make sense as an image format for the web: high fidelity images with bit rates at or below 1 bit/pixel. Nobody is browsing the web on a 16-bit panel and AVIF supports 12bpc images anyway. Unfortunately, JPEG XL authors chose not include AVIF when they performed a subjective image comparison in 2020 under controlled viewing conditions (https://research.google/pubs/benchmarking-jpeg-xl-lossylossless-image-compression/ https://research.google/pubs/benchmarking-jpeg-xl-lossylossl...), but previous subjective studies showed AVIF outperforming PIK and FUIF over the evaluated bit-rates.
  - janwas 2y ago
    I'm curious what the evidence is for AVIF outperforming below 1bpp? Have you seen this more recent data that includes AVIF? https://cloudinary.com/labs/cid22 https://cloudinary.com/labs/cid22
    - unlord 2y ago
      > Have you seen this more recent data that includes AVIF? https://cloudinary.com/labs/cid22 https://cloudinary.com/labs/cid22 The graph from Cloudinary uses libaom to do the encoding at speed preset 7 (aom s7), which is far from speed preset 0 and disables many AVIF coding tools. I do not know why this was chosen by the author, but it does not reflect AVIF performance. According to https://github.com/AOMediaCodec/libavif/issues/440#issuecomment-741968787 https://github.com/AOMediaCodec/libavif/issues/440#issuecomm... speed preset 8 loses 20-35% compression efficiency.
      - janwas 2y ago
        At a guess, probably because it matches or at least is in the same order of magnitude encode speed as JPEG XL? It starts to feel like bait and switch if we say "look what we can do with >1000x slower encode", without noting that JPEG XL can also do a bit better with more encode time, and yet practical encoders, especially HW, use much higher speed settings. Note: the 20-35% is BDrate, which in this context likely(?) involves some form of PSNR, which has almost nothing to do with human perception and IMO should not be used to guide such decisions.

by Latty 2y ago

OuterVale 2y ago

While that most definitely is a consideration, AVIF lacks many features and much of the functionality offered by JPEG XL. An investment in JPEG XL, while only being beneficial for one task like you say, would have huge benefits given just how many images we see and process on the web. AVIF certainly gets the hardware support advantage, but it fails in other regards where JPEG XL shines. Looking at it either way, JPEG XL is far from slow, and I'd argue that the other benefits outweigh that single shortcoming. Bandwidth should also be treated as a consideration, as you mentioned, and JPEG XL generally leads to smaller file sizes. Realistically, this boils down to AVIF being largely worse than JPEG XL, with the exception of performance. Performance that could be improved for JPEG XL should hardware vendors choose to provide better support.

Latty 2y ago
Any features that matter to consumers more than slightly better battery life? I haven't seen one yet despite people always touting "better features". It feels to me like JPEG XL's advantages are mostly hypothetical, and practically AVIF is the format that has more value. I'm no expert on this, to be clear, but I have yet to be convinced despite all the JPEG XL hype on HN.
- janwas 2y ago
  Disclosure: I worked on JPEG XL, opinions are my own. The radio(network) on phones can consume more power than the SoC(CPU). Thus smaller size can translate into energy savings. As to hypothetical advantage, we are talking about HW _potentially_ being used for image decode. AFAIK this does not happen in practice, despite WebP non-lossless being a VP8 frame and the hardware being plentifully available. As evidence for the advantages of JPEG XL being real, consider the fact that it is increasingly being adopted in serious SW including ACR, Darktable, Krita, and Lightroom.
  - Latty 2y ago
    JPEG XL is significantly smaller? All the stuff I've seen has show a slight edge for the same visual quality, but not enough I'd suspect it'd offset hardware decode, although if software doesn't actually do hardware decode, then yeah, the argument falls apart. I can 100% see JXL being adopted in production tools, where the motivations are different, I was mainly talking about the web adoption perspective for end users (which is the context of Google's supposed war on it, of course).
unlord 2y ago
> While that most definitely is a consideration, AVIF lacks many features and much of the functionality offered by JPEG XL. What features are these? You have not named a single concrete advantage. The places where AVIF out-performs JPEG XL are exactly where it make sense as an image format for the web: high fidelity images with bit rates at or below 1 bit/pixel. Nobody is browsing the web on a 16-bit panel and AVIF supports 12bpc images anyway. Unfortunately, JPEG XL authors chose not include AVIF when they performed a subjective image comparison in 2020 under controlled viewing conditions (https://research.google/pubs/benchmarking-jpeg-xl-lossylossless-image-compression/ https://research.google/pubs/benchmarking-jpeg-xl-lossylossl...), but previous subjective studies showed AVIF outperforming PIK and FUIF over the evaluated bit-rates.
- janwas 2y ago
  I'm curious what the evidence is for AVIF outperforming below 1bpp? Have you seen this more recent data that includes AVIF? https://cloudinary.com/labs/cid22 https://cloudinary.com/labs/cid22
  - unlord 2y ago
    > Have you seen this more recent data that includes AVIF? https://cloudinary.com/labs/cid22 https://cloudinary.com/labs/cid22 The graph from Cloudinary uses libaom to do the encoding at speed preset 7 (aom s7), which is far from speed preset 0 and disables many AVIF coding tools. I do not know why this was chosen by the author, but it does not reflect AVIF performance. According to https://github.com/AOMediaCodec/libavif/issues/440#issuecomment-741968787 https://github.com/AOMediaCodec/libavif/issues/440#issuecomm... speed preset 8 loses 20-35% compression efficiency.
    - janwas 2y ago
      At a guess, probably because it matches or at least is in the same order of magnitude encode speed as JPEG XL? It starts to feel like bait and switch if we say "look what we can do with >1000x slower encode", without noting that JPEG XL can also do a bit better with more encode time, and yet practical encoders, especially HW, use much higher speed settings. Note: the 20-35% is BDrate, which in this context likely(?) involves some form of PSNR, which has almost nothing to do with human perception and IMO should not be used to guide such decisions.