4 ms·

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

by hirako2000 19d 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 19d 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 19d 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 19d ago
    This is a thread and article about JPEG XL on the web.
    - throw0101a 19d 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").

jaffathecake 19d 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 19d 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 19d ago
  This is a thread and article about JPEG XL on the web.
  - throw0101a 19d 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").