[jmull]

> "But instead this was just another development thread Google single-handedly stopped out of nothing but ego?"

There's a reasonable cost/benefit argument against standardizing JPEG XL in browsers. You don't have to agree with it, but JPEG XL proponents shouldn't just ignore it.

The argument is: (1) the cost is large -- implementation and maintenance of a complex image codec takes time, and image codecs are high-risk from a security perspective. (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases.

Now, you don't have to agree with that argument -- e.g. you can argue the cost isn't that high, or that there are valuable advantages to jxl for significant use cases that aren't covered by existing alternative.

But you do need to engage that argument.

Otherwise what else do you have? Popular demand isn't going to work, because you're in a chicken-and-egg situation. I suppose you can try to bribe and/or bully key decision makers for all the major browsers, though I hope that wouldn't work.

[quackdoc]

I'm not sure how the benefit could be considered small, being able to perform lossless compression of JPEGs alone is such a massive benefit. In my testing I do every now and then which consists of ripping thousands of images from various websites (image boards, scraping from websites I visit) I regularly get 20-40% file size savings when transcoding JPEG to JXL. These aren't some small 256x256 icons or cherry picked image sets of 25 pictures people love to test. This is as much as a real world use test one could possibly get for web testing.

Completely ignoring the potential of replacing PNG or WEBP, Completely ignoring actually competing against AVIF. The benefits of JXL when it comes to losslessly saving space for pre-existing images is so massively significant, it's hard to believe that this single feature alone doesn't meet the bar of worth.

[alwillis]

> The benefits of JXL when it comes to losslessly saving space for pre-existing images is so massively significant, it's hard to believe that this single feature alone doesn't meet the bar of worth.

The old Google that cared deeply about the web would have been all over this. This current regime--not so much.

It's probably no coincidence that many of the folks who were huge advocates for the web are no longer there.

[alwillis]

> The argument is: (1) the cost is large -- implementation and maintenance of a complex image codec takes time, and image codecs are high-risk from a security perspective.

If you look at the history of Google employees created the basis for JPEG XL [1], having it included in beta builds of Chrome and then removing it "for reasons", it's pretty obvious it wasn't pulled for technical or security reasons.

Obviously Apple didn't think there were significant security and implementation issues preventing them from enabling JPEG XL on over 2 billion devices.

The Chrome team has proposed a number of web features and APIs that Apple, Mozilla and sometimes Microsoft don't want to implement due to security and privacy reasons. Usually that doesn't stop Chrome from going ahead and shipping them anyway.

> (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases.

JPEG XL does provide advantages over existing alternatives—The Case for JPEG XL [2]:

    In the past, new image formats have been introduced that brought
    improvements in some areas while also introducing regressions in
    others. For example, PNG was a great improvement over GIF,
    except that it did not support animation. WebP brought
    compression improvements over JPEG in the low to medium fidelity
    range but at the cost of losing progressive decoding and
    high-fidelity 4:4:4 encoding. AVIF improved compression further,
    but at the cost of both progressive decoding and deployable
    encoders.

    We looked at six aspects of JPEG XL where it brings significant
    benefits over existing image formats:

    * Lossless JPEG recompression (20% on average)

    * Progressive decoding

    * Lossless compression performance

    * Lossy compression performance

    * Deployable encoder

    * Works across the workflow

[1]: https://github.com/google/pik

[2]: https://cloudinary.com/blog/the-case-for-jpeg-xl

[jmull]

I don't have a strong opinion either way, but I'll play devil's advocate here...

> Lossless JPEG recompression (20% on average)

Lossless JPEG recompression isn't that valuable because it's a "tweener" solution. If you mainly just care about image size, you can live with some loss and can recompress jpegs using existing formats. Or if you care about size and quality, you can recompress from high-quality sources using existing formats. lossless jpeg recompression kind of fits in the middle somewhere... you care enough about size to go through the trouble to recompress, but you don't care so much that you will use high-quality sources and you care about quality enough that you don't want to lose quality when recompressing, but again not so much that you will use high-quality sources. So it's not nothing, but not great either.

> Progressive decoding

A solution to a vanishing edge case.

> Lossless compression performance

Explains why you might want to use jxl in your workflow but that's not a browser concern.

> Lossy compression performance

This sounds good, but is it enough better over existing formats to justify a new one in the browser? I don't think it's clear cut.

> Deployable encoder

Obviously, existing formats have deployed encoders.

> Works across the workflow

Not a browser concern. Note that even if you use jxl across your entire workflow, you're still going very typically have a publishing step for images where you find and use a level of compression/quality appropriate for your project. There's not really any particular difference if the general image format type has changes at this step or not.

[themerone]

The big benefit of progressive decoding is one high resolution file supports responsive apps that can fetch smaller images just by download part of the full file.

[jmull]

"responsive app can fetch smaller images" is not really exclusive to jxl though.

For any format you can store an image at multiple resolutions/quality-levels and a responsive app can download the one with the size/quality it wants.

jxl probably saves an incremental amount of storage, which is nice, but storage is not usually the dominant cost of anything. So this is still an edge case.

[themerone]

That's only true because you took my quote completely out of context.

The point is not needing to store multiple copies of an image. You can simplify the back-end if you serve the same file to all clients.

[spider-mario]

> lossless jpeg recompression kind of fits in the middle somewhere... you care enough about size to go through the trouble to recompress, but you don't care so much that you will use high-quality sources and you care about quality enough that you don't want to lose quality when recompressing, but again not so much that you will use high-quality sources.

You’re assuming that the high-quality original is still available. If the JPEG is all you have, then losslessly recompressing it is the smallest file of the highest quality you can get.

[jmull]

If you don't keep track of the high-quality originals, how much do you really care about having the highest quality?

That's what I mean by "tweener" solution. You care a little about quality because you don't want to lose any more that you already have lost in your jpg, but not so much that you're keeping track of the high-quality originals. It's not nothing, but it's also not a big deal.

[cjawdb]

"A solution to a vanishing edge case" is a wild-ass statement to make about progressive decoding.

[spider-mario]

There is popular demand (including from Adobe https://github.com/web-platform-tests/interop/issues/430#iss..., https://crbug.com/40168998#comment62), which is arguably evidence against (2).

(Disclaimer: I’m a JPEG XL contributor.)