3 ms·

With your logic we should quickly remove WebP and AVIF, and have an active discussion if JPEG XL is good enough to make it. Also port as much as possible from J

With your logic we should quickly remove WebP and AVIF, and have an active discussion if JPEG XL is good enough to make it. Also port as much as possible from JPEG XL tech into traditional JPEG.

pornel 4y ago
That's not what I was trying to say. You know that it's impossible to remove WebP from the web platform any more. I do think it'd be nice to have a plan for removal of AVIF from the platform, but I don't know if AV1 video will become unremovable. Porting of new features to the old JPEG has been attempted in JPEG XT, but it didn't take off. It sucks that the codec with the best quality/filesize ratio doesn't just win. There are many other factors beyond this, e.g. • There's a lot of inertia keeping old codecs alive, which is from "just works" that has been from merely being old and popular. There's a whole graveyard of JPEG-killers that have beaten it on features and compression. GIF isn't even "good enough" technically, and it still refuses to die, because it's just so old to be universally supported. JPEG XL hasn't done the legwork yet to be everywhere, and isn't old enough yet to be everywhere including old software. • Browser vendors' default resistance to ever-growing complexity of the platform, code size, and attack surface. I think JPEG XL's ability to be both non-Web editing format and Web format is actually working against it here, because the Web platform doesn't want non-Web features. Browsers haven't even implemented AVIF as specced, only a bare minimum subset. JPEG XL doesn't have a minimal subset.
- JyrkiAlakuijala 4y ago
  JPEG XL can be fully implemented in 50-150 kB, and now you tell that AVIF implementations in browsers at 500+ kB are bare minimum subsets.
  - pornel 4y ago
    The major cost is on the AV1 side, which is there for video and which JPEG XL can't replace. The extra cost of recycling existing MP4+AV1 code to handle AVIF is minimal, smaller than JPEG XL can be.
    - jonsneyers 4y ago
      Then again, libjpeg-turbo could probably be dropped if we spend some effort on making libjxl also decode jpegs (and encode them, since browsers also need to do be able to do that for jpeg). I think that could reduce the net cost of adding jxl quite a bit — libjpeg-turbo has quite some code and API functions that browsers don't actually need at all, and all it really needs to do is already there in libjxl. So a variant of the "two for one" argument that justifies AVIF can also be used to justify JXL, since JPEG is needed anyway, even more so than AV1. Also I am not so sure if the delta between AV1-only and AVIF is _that_ small, after all you do need to take care of alpha, color management, HDR, animation, and I suppose quite different code paths to get the decoded pixels in the right place than what is already there for the video case. Plus it looks like new things are still getting added to avif, like YCoCg-R and progressive previews, so it feels like it's a bit of a "moving target" spec like webp was in the early days. I see quite a few opportunities for bugs, different levels of support between different browser (versions), etc, that are not caused by AV1 itself but just by AVIF.
- jonsneyers 4y ago
  JXL currently has two levels: Level 5 (intended for browsers), allows no CMYK, limits the number of channels to 7, limits the maximum lossless bitdepth to 14-bit or so (the actual criterion is that the intermediate buffers can be implemented using int16_t, so the actual bitdepth limit depends on what bitdepth-widening or -narrowing transformations the encoder used), and has some more limits like that. Level 10 allows nearly anything the bitstream syntax allows, with a few "sanity check" type limits. All of the coding tools and format features in the jxl spec do have useful potential applications for the Web, except for CMYK and very high precision lossless (and this is why a decoder conforming only to level 5 does not need to handle those). E.g. layers can be useful just for compression too (e.g. a text overlay on a photo background will likely compress better / with less artifacts if it is kept in layers). The nice thing about jxl is that everything needed to display an image is specced in the codestream and handled by libjxl itself, so no need for a browser (or any other application) to implement these things themselves — and possibly not implement some of them, or not quite correctly. In avif (like in heic), a lot of codestream gaps have to be filled at the file format level (e.g. alpha), and that inevitably leads to bugs and differences between the different browsers/viewers.

With your logic we should quickly remove WebP and AVIF, and have an active discussion if JPEG XL is good enough to make it. Also port as much as possible from JPEG XL tech into traditional JPEG.

pornel 4y ago

That's not what I was trying to say. You know that it's impossible to remove WebP from the web platform any more. I do think it'd be nice to have a plan for removal of AVIF from the platform, but I don't know if AV1 video will become unremovable. Porting of new features to the old JPEG has been attempted in JPEG XT, but it didn't take off. It sucks that the codec with the best quality/filesize ratio doesn't just win. There are many other factors beyond this, e.g. • There's a lot of inertia keeping old codecs alive, which is from "just works" that has been from merely being old and popular. There's a whole graveyard of JPEG-killers that have beaten it on features and compression. GIF isn't even "good enough" technically, and it still refuses to die, because it's just so old to be universally supported. JPEG XL hasn't done the legwork yet to be everywhere, and isn't old enough yet to be everywhere including old software. • Browser vendors' default resistance to ever-growing complexity of the platform, code size, and attack surface. I think JPEG XL's ability to be both non-Web editing format and Web format is actually working against it here, because the Web platform doesn't want non-Web features. Browsers haven't even implemented AVIF as specced, only a bare minimum subset. JPEG XL doesn't have a minimal subset.

JyrkiAlakuijala 4y ago
JPEG XL can be fully implemented in 50-150 kB, and now you tell that AVIF implementations in browsers at 500+ kB are bare minimum subsets.
- pornel 4y ago
  The major cost is on the AV1 side, which is there for video and which JPEG XL can't replace. The extra cost of recycling existing MP4+AV1 code to handle AVIF is minimal, smaller than JPEG XL can be.
  - jonsneyers 4y ago
    Then again, libjpeg-turbo could probably be dropped if we spend some effort on making libjxl also decode jpegs (and encode them, since browsers also need to do be able to do that for jpeg). I think that could reduce the net cost of adding jxl quite a bit — libjpeg-turbo has quite some code and API functions that browsers don't actually need at all, and all it really needs to do is already there in libjxl. So a variant of the "two for one" argument that justifies AVIF can also be used to justify JXL, since JPEG is needed anyway, even more so than AV1. Also I am not so sure if the delta between AV1-only and AVIF is _that_ small, after all you do need to take care of alpha, color management, HDR, animation, and I suppose quite different code paths to get the decoded pixels in the right place than what is already there for the video case. Plus it looks like new things are still getting added to avif, like YCoCg-R and progressive previews, so it feels like it's a bit of a "moving target" spec like webp was in the early days. I see quite a few opportunities for bugs, different levels of support between different browser (versions), etc, that are not caused by AV1 itself but just by AVIF.
jonsneyers 4y ago
JXL currently has two levels: Level 5 (intended for browsers), allows no CMYK, limits the number of channels to 7, limits the maximum lossless bitdepth to 14-bit or so (the actual criterion is that the intermediate buffers can be implemented using int16_t, so the actual bitdepth limit depends on what bitdepth-widening or -narrowing transformations the encoder used), and has some more limits like that. Level 10 allows nearly anything the bitstream syntax allows, with a few "sanity check" type limits. All of the coding tools and format features in the jxl spec do have useful potential applications for the Web, except for CMYK and very high precision lossless (and this is why a decoder conforming only to level 5 does not need to handle those). E.g. layers can be useful just for compression too (e.g. a text overlay on a photo background will likely compress better / with less artifacts if it is kept in layers). The nice thing about jxl is that everything needed to display an image is specced in the codestream and handled by libjxl itself, so no need for a browser (or any other application) to implement these things themselves — and possibly not implement some of them, or not quite correctly. In avif (like in heic), a lot of codestream gaps have to be filled at the file format level (e.g. alpha), and that inevitably leads to bugs and differences between the different browsers/viewers.