3 ms·

Browsers already fully support 4:4:4 AVIF and are not going to regress on this, as it would be a huge compat issue. It isn't clear whether AVIF hardware decodi

Browsers already fully support 4:4:4 AVIF and are not going to regress on this, as it would be a huge compat issue. It isn't clear whether AVIF hardware decoding will ever be an advantage, but for video formats, Firefox and Chrome already pick between hardware and software decoders to ensure the content plays correctly. Safari is much flakier here, but again, for images, they're not going to regress on 4:4:4 AVIF support.

hirako2000 26d ago
Lossless AVIF encoding is inferior to JXL though, the article oddly dismisses lossless as a valid case for the web so it ignores the core argument that lossless is critical for some type of content. I find the hardware support argument far more compelling that diminishing the value of lossless publishing.
- jaffathecake 26d ago
  I think the need for lossless images within a web page is extremely niche. I've used them before when comparing image codecs, but that's about it. In cases where you need lossless, WebP is there. It's close to JPEG XL's performance, sometimes beats it, and is orders of magnitude faster to decode.
  - throw0101a 26d ago
    > I think the need for lossless images within a web page is extremely niche. Sure, but if companies are going to put in the effort to support a format, you might as well work towards supporting the 'full capabilities' of it, that way it can be used in as many workflows as possible. You want your camera, photo editing software, colour correction process, etc, to support lossless. One of your final outputs may be for the web where lossless is not important, but there may be others as well (e.g., as a graphic in a video production).
    - jaffathecake 26d ago
      This is a thread and article about JPEG XL on the web.
      - throw0101a 26d ago
        JPEG XL on the web does not arrive there ex nihilo: there is a production pipeline that creates and puts files on web servers and points to those files in HTML tags. That production pipeline may also be used to generate images for things besides the web, so the creators have the choice of having one set of files used everywhere, or one set for the web and a second set for other things. That JXL lossless is overkill for the web may be overridden by the fact that people don't want to deal with the hassle of multiple sub-sets of files (i.e., laziness or "efficiency").

hirako2000 26d ago

Lossless AVIF encoding is inferior to JXL though, the article oddly dismisses lossless as a valid case for the web so it ignores the core argument that lossless is critical for some type of content. I find the hardware support argument far more compelling that diminishing the value of lossless publishing.

jaffathecake 26d ago
I think the need for lossless images within a web page is extremely niche. I've used them before when comparing image codecs, but that's about it. In cases where you need lossless, WebP is there. It's close to JPEG XL's performance, sometimes beats it, and is orders of magnitude faster to decode.
- throw0101a 26d ago
  > I think the need for lossless images within a web page is extremely niche. Sure, but if companies are going to put in the effort to support a format, you might as well work towards supporting the 'full capabilities' of it, that way it can be used in as many workflows as possible. You want your camera, photo editing software, colour correction process, etc, to support lossless. One of your final outputs may be for the web where lossless is not important, but there may be others as well (e.g., as a graphic in a video production).
  - jaffathecake 26d ago
    This is a thread and article about JPEG XL on the web.
    - throw0101a 26d ago
      JPEG XL on the web does not arrive there ex nihilo: there is a production pipeline that creates and puts files on web servers and points to those files in HTML tags. That production pipeline may also be used to generate images for things besides the web, so the creators have the choice of having one set of files used everywhere, or one set for the web and a second set for other things. That JXL lossless is overkill for the web may be overridden by the fact that people don't want to deal with the hassle of multiple sub-sets of files (i.e., laziness or "efficiency").