Comments

You must log in or register to comment.

happyscrappy t1_iuge747 wrote

Firefox didn't support it. Chrome didn't support it without an experimental feature flag on. Not sure about Safari.

But sounds like there's no reason to be surprised there isn't much demand for JPEG XL support. Who would serve JPEG XL pics when browsers don't display it?

14

9-11GaveMe5G t1_iugna5e wrote

I'm all for shitting on chrome, but when FF never bothered to support it either, makes me think it just didn't have a compelling use case for browsers in general

8

littleMAS t1_iugjsr7 wrote

Safari supports JPEG2000, which has been around a long time and gotten little traction. The web seems to favor the lowest common denominators, e.g., GIF.

5

xeeeeeeeeeeeeeeeeenu t1_iugbok7 wrote

I find their justification baffling. They claim there's "not enough support from the community" despite companies like Adobe, Cloudflare, Facebook, Flickr, Shopify etc. openly endorsing the format. And it's not like there was more hype for AVIF.

"Not sufficient incremental benefits over existing formats" is also surprising: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs

6

gurenkagurenda t1_iugn8q9 wrote

The specific wording is:

> There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL

I think what they mean is that other browsers weren't moving to support it (no Safari support, and Firefox support only in nightlies, afaict).

This really doesn't seem that baffling to me. At the very least least, I don't have to speculate very far to make it seem anything other than mundane.

For example, suppose one engineer took this support on as their pet project, and now they've moved on to other things (pretty typical at Google, from what I understand). Image decoders are complicated, highly optimized code, so they're ripe for security flaws and have to be actively maintained. So you've got a possible attack vector with no maintainer, which nobody is actually using (because it's behind a flag), and no new movement on it becoming a de facto web standard. And of course, the spec is right there (as is the old code), so if that situation changes, you can just put it back and actually dedicate resources to it. That all sounds like business as usual in the software industry.

5

xeeeeeeeeeeeeeeeeenu t1_iugrfyl wrote

> I think what they mean is that other browsers weren't moving to support it (no Safari support, and Firefox support only in nightlies, afaict).

Chrome was the first browser to support WebP and AVIF, they didn't wait for other vendors to implement it. In practice Google is the one who dictates web standards, the others follow them. It's not surprising considering that Blink-based browsers have >70% market share.

>This really doesn't seem that baffling to me. At the very least least, I don't have to speculate very far to make it seem anything other than mundane.

>For example, suppose one engineer took this support on as their pet project, and now they've moved on to other things (pretty typical at Google, from what I understand). Image decoders are complicated, highly optimized code, so they're ripe for security flaws and have to be actively maintained. So you've got a possible attack vector with no maintainer, which nobody is actually using (because it's behind a flag), and no new movement on it becoming a de facto web standard. And of course, the spec is right there (as is the old code), so if that situation changes, you can just put it back and actually dedicate resources to it. That all sounds like business as usual in the software industry.

Right, and none of those considerations apply to WebP and AVIF. In fact, AVIF was enabled by default in production releases immediately, there was no experimental period.

5

gurenkagurenda t1_iuhcw08 wrote

Sure, they’re playing favorites with the tech they’ve invested in and backed. The point is that the JPEG-XL situation is the normal case.

If the principal leans on a teacher and they give a passing grade to the star football player so he remains in good academic standing, but then the teacher fails another student who has a similar performance, there’s nothing baffling about either case, and certainly not about the student the teacher failed. The favoritism is bad, but the fact that they failed the one student is the normal situation.

4

empirebuilder1 t1_iugn2u2 wrote

I'm assuming JPEG-XL is getting killed because WEBP, which is fully google home-grown-and-owned, not built by a consortium that just happens to include google, has already supplanted it.

3

atomic1fire t1_iugrymi wrote

Plus AVIF exists, and is created by a group that includes google.

I feel like JPEG/MPEG/ etc are holdovers from when large patent bodies created formats with the expectation that they'd all get revenue from the licensing, while the AOM creates royalty free codecs since they don't care about the licensing fees, because they're more concerned with formats that do what they want and don't require paying out of pocket for encoding/decoding in high demand.

Plus the licensing fees creates a barrier to adoption, since people will go with whatever the cheapest/free-est solution is.

2

Temenes t1_iugvgti wrote

JPEG XL is royalty free.

4

atomic1fire t1_iujkn4h wrote

Sure, but I was moreso refering to the group JPEG, not the most recent format.

I might be blaming the standards bodies themselves when the patent holders might be more responsible.

There's a whole PDF/slideshow about the patent troubles encountered by the original JPEG group, namely that Patents still covered a bunch of stuff for years and none of the patent holders waived their right to sue, so what happens is the people using the jpeg format have to pay any of the relevent patent holders to use the format.

The original goal of JPEG was apparently to be royalty free, but it couldn't do that with the patents holders around at the time.

https://www.ecma-international.org/wp-content/uploads/IS-presentation-to-JTC1SC29WG1-regarding-JPEG25-celebration.pdf

1