4 ms·

No loss there, just slowdown and additional complexity for the web devs to deal with. Jpeg xl covers several important domains that are not served by AVIF. Jpe

No loss there, just slowdown and additional complexity for the web devs to deal with. Jpeg xl covers several important domains that are not served by AVIF. Jpeg xl will anchor in these domains and where AVIF cannot provide sufficient quality or speed. Eventually it cannot be ignored any more and will be made available in browsers, too. Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.

deleted 4y ago
[deleted]
CharlesW 4y ago
> Jpeg xl covers several important domains that are not served by AVIF. I'm not finding any. Mind listing them? > Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again. Unfortunately, JPEG XL wasn't "better enough" to have a unique selling proposition. And AVIF is the format that actually simplifies things, because it uses the same compressed media format (AV1) as the next-gen video distribution format.
- mort96 4y ago
  >> Jpeg xl covers several important domains that are not served by AVIF. > I'm not finding any. Mind listing them? I don't know much about JXL vs AV1 from a technical perspective, both seem significantly better than JPEG. But JXL has the practical advantage that it can losslessly recompress JPEG images for a size improvement without an image quality improvement. When converting JPEG to AV1, you're stuck decompressing the JPEG into raw pixel data, with JPEG artefacts and all, and then compress that pixel data with AV1, so you get the artefacts from JPEG and the artefacts from AV1. Decompressing the resulting AV1 image will result in different and almost certainly worse quality pixel data. So the ability to do a risk-free lossless conversion from JPEG to a better format and get a size improvement is a pretty darn big domain that's not served by AV1.
  - CharlesW 4y ago
    Thanks!
- astral303 4y ago
  But video is not the same as still imagery. Different tradeoffs must be made for motion.
  - masklinn 4y ago
    Like BPG and HEIF, AVIF is based on keyframes (i-frames). There's no tradeoff because there is no motion, the point of keyframes is to reset the entire frame. Keyframes are still images embedded in the video stream.
    - lifthrasiir 4y ago
      Keyframes are meant to be visible for less than 100 milliseconds in typical cases. Not to say that AV1 is bad at still images, but there are tradeoffs associated to this fact ("low fidelity imagery").
      - CharlesW 4y ago
        > Keyframes are meant to be visible for less than 100 milliseconds in typical cases. Keyframes don't disappear with the next frame — they're the basis of all the delta (P- and B-) frames that follow until the next I-frame. Also, AVIF does support features like progressive encoding/decoding¹, which may be the kind of "still image only" tradeoff you're thinking of. ¹ https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-items https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-...
        lifthrasiir 4y ago
        > Keyframes don't disappear with the next frame — they're the basis of all the delta (P- and B-) frames that follow until the next I-frame. Exactly this. P/B-frames are not encoded as a delta to the input I-frame; it is encoded as a delta to once compressed then decoded I-frame, otherwise errors in the I-frame will accumulate. So any imperfection in I-frames has a chance to be fixed by subsequent P/B-frames, but this is impossible in a still image. You have a good point that AVIF layered image items can act like such P/B-frames. Do libavif (or other AVIF implementations if any) make use of them? JPEG XL has the same feature (zero-duration frame) but I think libjxl doesn't use it to encode a residue when the input image is not animated---in fairness such residues are very hard to compress though.
youngtaff 4y ago
There’s also the challenge that AVIF isn’t cheap to transcode Getting a cache miss with Cloudinary on large avifs can sometimes result in a multi second delay while they’re generated Lack of JXL support is going to cost sites that server huge numbers of images e.g. Cloudinary millions of dollars in extra compute power

deleted 4y ago

[deleted]

CharlesW 4y ago

> Jpeg xl covers several important domains that are not served by AVIF. I'm not finding any. Mind listing them? > Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again. Unfortunately, JPEG XL wasn't "better enough" to have a unique selling proposition. And AVIF is the format that actually simplifies things, because it uses the same compressed media format (AV1) as the next-gen video distribution format.

mort96 4y ago
>> Jpeg xl covers several important domains that are not served by AVIF. > I'm not finding any. Mind listing them? I don't know much about JXL vs AV1 from a technical perspective, both seem significantly better than JPEG. But JXL has the practical advantage that it can losslessly recompress JPEG images for a size improvement without an image quality improvement. When converting JPEG to AV1, you're stuck decompressing the JPEG into raw pixel data, with JPEG artefacts and all, and then compress that pixel data with AV1, so you get the artefacts from JPEG and the artefacts from AV1. Decompressing the resulting AV1 image will result in different and almost certainly worse quality pixel data. So the ability to do a risk-free lossless conversion from JPEG to a better format and get a size improvement is a pretty darn big domain that's not served by AV1.
- CharlesW 4y ago
  Thanks!
astral303 4y ago
But video is not the same as still imagery. Different tradeoffs must be made for motion.
- masklinn 4y ago
  Like BPG and HEIF, AVIF is based on keyframes (i-frames). There's no tradeoff because there is no motion, the point of keyframes is to reset the entire frame. Keyframes are still images embedded in the video stream.
  - lifthrasiir 4y ago
    Keyframes are meant to be visible for less than 100 milliseconds in typical cases. Not to say that AV1 is bad at still images, but there are tradeoffs associated to this fact ("low fidelity imagery").
    - CharlesW 4y ago
      > Keyframes are meant to be visible for less than 100 milliseconds in typical cases. Keyframes don't disappear with the next frame — they're the basis of all the delta (P- and B-) frames that follow until the next I-frame. Also, AVIF does support features like progressive encoding/decoding¹, which may be the kind of "still image only" tradeoff you're thinking of. ¹ https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-items https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-...
      - lifthrasiir 4y ago
        > Keyframes don't disappear with the next frame — they're the basis of all the delta (P- and B-) frames that follow until the next I-frame. Exactly this. P/B-frames are not encoded as a delta to the input I-frame; it is encoded as a delta to once compressed then decoded I-frame, otherwise errors in the I-frame will accumulate. So any imperfection in I-frames has a chance to be fixed by subsequent P/B-frames, but this is impossible in a still image. You have a good point that AVIF layered image items can act like such P/B-frames. Do libavif (or other AVIF implementations if any) make use of them? JPEG XL has the same feature (zero-duration frame) but I think libjxl doesn't use it to encode a residue when the input image is not animated---in fairness such residues are very hard to compress though.

youngtaff 4y ago

There’s also the challenge that AVIF isn’t cheap to transcode Getting a cache miss with Cloudinary on large avifs can sometimes result in a multi second delay while they’re generated Lack of JXL support is going to cost sites that server huge numbers of images e.g. Cloudinary millions of dollars in extra compute power