8 ms·

This is worth looking at: https://caniuse.com/jpegxl https://caniuse.com/jpegxl Unless I'm misunderstanding that, no browser actually ever supported JPEG-XL w

This is worth looking at: https://caniuse.com/jpegxl https://caniuse.com/jpegxl Unless I'm misunderstanding that, no browser actually ever supported JPEG-XL without a flag (or at all on Safari's cases). No OS appears to have supported it natively either[0]. The reality is that formats have a chicken & egg problem. Normally Google deserves to get dunked on, but in this case, why is Google the scapegoat instead of the entire industry that didn't adopt it? Feels like there is a bigger issue with JPEG-XL's failure to launch, and they did more than some (Apple? Microsoft?). [0] https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a...

brookst 4y ago
Yep. This is like teenagers blaming Walmart for their band's lack of success. "If only they had carried our album and featured it on endcaps!"
- zinekeller 4y ago
  Yep, teenagers like Facebook and Adobe - oh wait. Maybe Google is now flexing its anticompetitive muscles now, isn't it?
  - brookst 4y ago
    I must be failing to understand your comment. The people complaining are FSF, and no matter how hard I squint, I cannot see how fair competition could require Google to be the first one to support a standard that literally nobody else supports.
    - zinekeller 4y ago
      > The people complaining are FSF Nope, not just FSF. The Chromium team have prototyped JXL, but removed it initially for unknown reasons (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c183 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...). Engineering teams including but not limited to Adobe, Facebook, Intel and Shopify have complained about its abrupt removal. Chromium developers have subsequently said that it was "due to low interest" (despite piles of messages from engineering teams both in leading companies and small groups saying otherwise). > I cannot see how fair competition could require Google to be the first one to support a standard that literally nobody else supports. First, Adobe products have just included JXL. Second, It's because Google is pushing for AVIF, which was extended from AV1. While it has some advantages (as essentially extended version from AV1), it also has a lot of disadvantages: https://news.ycombinator.com/item?id=35590516 https://news.ycombinator.com/item?id=35590516. No one said to remove AVIF in favor of JXL and in fact there are instances where AVIF is the better choice (animated images due to its interframe support) but instead to support JXL regardless of Google's support of AVIF, and some people have seen it as forcing Google-favored AVIF instead of considering all formats developed (like how WebP was rammed a decade ago).
      - SquareWheel 4y ago
        > but removed it initially for unknown reasons Just an FYI, they gave their reasons in comment #84 of the thread you linked.
  - brigade 4y ago
    Adobe didn't support WebP until 2021, they're the poster child for not supporting a format until it's popular enough that they need to add support.
- quadrangle 4y ago
  There's also the more widespread phenomenon of profitable-enough local businesses blaming Walmart for putting them out of business. How do we evaluate which analogy is appropriate?
adgjlsfhk1 4y ago
Google has 90% of the market. They are the industry.
- izacus 4y ago
  So they're now forced to maintain every single format someone invents, keep it compatible and security patched forever? Even though even FOSS champion Mozilla wouldn't touch it?
  - ksec 4y ago
    >So they're now forced to maintain every single format someone invents, Or they could pick a better format and evaluate it? The question is why the better format here, even though it is the same royalty free ( or patents free in AOM's term ), wasn't picked.
    - mynameisvlad 4y ago
      They could. They could also choose to not to. They could also have done it and their set of reasons doesn’t align with yours. They’re a private company. They can choose to do whatever they want or don’t want to. If they don’t want to support JPEGXL, why should they be forced to do it? If it was such a necessary format, it would have been a competitive disadvantage to not have support and that would have forced their hand, but nobody else supports it either so why should Google be forced to if they (clearly) don’t want to.
      - ksec 4y ago
        They dont have to. But they could also not lie about it. Or lie about do no evil ( I know that is no longer their motto ). Or they could also not lie about WebP, AOM or AMP or everything else about being Good.
        mynameisvlad 4y ago
        I mean they could do all those things, but, once again, they don’t have to. They don’t have a responsibility to anyone but their shareholders and therefore bottom line.
csdreamer7 4y ago
> No OS appears to have supported it natively either[0]. Not sure what you mean by OS. The link you provided shows that Linux with several GNOME and other tools support JPEG-XL (especially GIMP).
- eviks 4y ago
  But it's not "native"!
0x_rs 4y ago
>instead of the entire industry that didn't adopt it? Is this a good argument? Nobody is going to adopt something without being natively supported by browsers without ugly js hacks, and when it comes to browser standards it seems to me Google has more leverage than anybody else. Cloudinary has made a lot of posts about JPEG-XL, so you might say they're quite biased towards it, but it also seems to me there is some interest in it by multiple companies [0, 1]. I personally very much doubt webp would be anywhere today without the massive (arguably deceptive) campaigning and double standards it had. 0. https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a... 1. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c16 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
- SquareWheel 4y ago
  > Nobody is going to adopt something without being natively supported by browsers without ugly js hacks That's fair, but it is worth pointing out that <picture> tags support multiple source formats. I serve some logos and other important images as both .png and .webp. Adding additional lines for avif for jxl seem reasonable - especially if browsers are testing new formats.
- mynameisvlad 4y ago
  Why should Google be the ones solely responsible for pushing forward file formats? Either you criticize everyone for their parts in not adopting it, or not at all. It seems silly to single out Google and Google alone when nobody else batted an eyelash to try and support the format.
  - demonshreder 4y ago
    The majority market share is for Google Chrome, directly and indirectly, thus they are the primary target, while Firefox & Safari will only come next.
- jsnell 4y ago
  Being supported by some browsers is useless. It needs to be supported by all the major browsers, as shown by webp. Apple did not support JPEG XL, based on past history was unlikely to do so, and despite what you say about Google having the most leverage they have none on Apple. If Apple doesn't want something supported, no iOS browser will support it. And if no iOS browser supports a format, it is not going to be useful in production. I do find it hilarious that all the people who complained about Chrome supporting webp then went on to complain about Chrome not supporting JPEG XL. They're both Google-created formats not widely supported by the ecosystem!
ksec 4y ago
>The reality is that formats have a chicken & egg problem. The same company that gave us WebP. At least Mozilla and Safari did the sane thing and push back against it.
- bastawhiz 4y ago
  Is your argument that more folks should have pushed back against JPEG XL? Webp was initially released in 2010 when it was the best alternative. JPEG XL came along almost a decade later. The state of image formats is very different.
  - zinekeller 4y ago
    No, instead Google should made WebP a proof-of-concept that there are technological advancements that can improve and made a successor of WebP like they've done with QUIC (to HTTP 3), not force-slinging it to everyone. Also, WebP violates the "two independent implementations" standard - at least AVIF can be argued to have two different implementations (due to dav1d).
- Spivak 4y ago
  Huh? Is there some drama because they all support webp so clearly push didn't come to shove.
kps 4y ago
> [0] https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a... JPEG XL is a general purpose image format, like JPEG and PNG, but improved. WebP is not a serious modern image format; it doesn't even support 16-bit channels. WebP has one specific purpose: web delivery of ephemeral images, leveraging VP8 hardware decoding driven by consumer consumption devices. That's what Google, and web-oriented companies in general, care about. They have no particular interest in general purpose image formats.
- Spivak 4y ago
  That seems fine then? Browsers are consumer consumption devices. And you have different formats good for other things. That's Apple's philosophy for HEIC.
  - webkike 4y ago
    No they are not. They are information delivery devices being co-opted for content consumption
  - kps 4y ago
    Although I'm not personally a fan of web apps or Electron, the reality is that browsers are not just consumer consumption devices. And my reading of http://crbug.com/1178058 http://crbug.com/1178058 is that the existence of WebP and AVIF is being used as a justification for removing JPEG XL support.
- GoblinSlayer 4y ago
  Here have it: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/...
GuB-42 4y ago
The problem is that old PNG and JPEG are good enough for most purposes. They are certainly not as efficient but with todays technology and bandwidth, there is little downside to using JPEG and you know it will be supported everywhere. It is not the case for video. Video is still a huge bandwidth hog, and finding better codecs is worth it, that's why they get better support. Webp is a clever hack as it is essentially a single frame webm video, so if you have webm support, which is worth it, then you can have webp almost for free, JPEG-XL doesn't have that incentive.
- kevin_thibedeau 4y ago
  Webp max resolution is 16383 x 16383. That is a problem in some applications.
  - selcuka 4y ago
    Why any modern image spec should have a maximum resolution is beyond me.
    - jonas21 4y ago
      WebP is based on VP8, which is a video format. Video formats can have maximum resolutions to make it easier to implement hardware decoders.
  - flangola7 4y ago
    What application? That's 8x 8K or 32x 4K. Even theoretical futuristic giant displays would not need that.
    - jerryX 4y ago
      Many smartphones now have 200MP e.g. allowing to crop, in astronomy they count in gigapixels ...
      - flangola7 4y ago
eviks 4y ago
There are many reasons, just to list a couple: 1) Chrome is much bigger, so it's much more consequential, so it's valid is a bigger target for criticism 2) It's much easier to performantly support the format on some OS without it being "native", so again, lack of browser support is worse, and thus it's valid it's a bigger target for criticism
unethical_ban 4y ago
You see it's chicken and egg, but then ask why people are upset that the giant chicken with the ability to put out 10,000 eggs a week dropped a feature that was already in their product.
illiarian 4y ago
> https://caniuse.com/jpegxl https://caniuse.com/jpegxl This is kinda how standards are supposed to work: at least two independednt implementations [1], released behind a flag to gather developer and user feedback. However it seems that in the end it went nowhere. [1] See Implementation experience: https://www.w3.org/2021/Process-20211102/#implementation-experience https://www.w3.org/2021/Process-20211102/#implementation-exp... Among other considerations: "are there independent interoperable implementations of the current specification?"
- ars 4y ago
  It's the "behind a flag" part that is the issue. How are you supposed to get feedback for a feature people can't actually use? It's like when Debian removed a package I use that was not shipped under the rationale that "no one uses it". Obviously no one uses it - you never actually shipped it, you just had the source available if people wanted to compile it.
  - illiarian 4y ago
    > How are you supposed to get feedback for a feature people can't actually use? The moment it's out there (that is, not behind a flag), you cannot fix it, update it etc. because people will be relying on the observed behaviour. The hard part is advertising the feature (at the very least to developers) because there are just too many featurs in modern browsers. Edit: for example, Chrome has Origin Trials https://developer.chrome.com/origintrials/#/trials/active https://developer.chrome.com/origintrials/#/trials/active for experimental features.
    - ars 4y ago
      Sure you can - you just do it. You just make the necessary fix. But you do it quickly, within a short time of launching it. Anyone who was able to make use of it within a couple months, will be able to adapt and fix things. Once it's been there for a year, then sure, people rely on it. But there's no reason to take so long.
      - 4y ago
croes 4y ago
It's not really a chicken egg problem. If a browser doesn't support a format as default nobody will use it unless big players like Apple or Google enforce it. If Jpeg XL had been enabled some time without a flag they could claim > There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL but hidden behind a flag there is no way to know. How many users enable experimental features in their browser?
crote 4y ago
Yeah, because it is a new format. You don't immediately publicly release support for an experimental format. Chrome added support for the in-progress version of JPEG XL in April 2021. The core coding specification was finished in March 2022, and the last part of the spec wasn't done until October 2022. Chrome removed it in December 2022, citing a "lack of interest from the ecosystem", despite it having support in most major image editors already. It was a new format which was rapidly being adopted and a lot of major players were very excited about it, but Chrome's removal pretty much killed it due to their dominance in the browser space. At the time of removal, it had better support than HEIC!
- pjmlp 4y ago
  Similar to how they killed WebGL 2.0 compute, actually.
- tourmalinetaco 4y ago
  All while they support WebP, which doesn’t appear to have any support anywhere beyond web browsers.
- jorvi 4y ago
  > At the time of removal, it had better support than HEIC! I don't think I've ever encountered a single JPEG-XL image. Meanwhile I've encountered plenty of HEIC and never encountered a problem in dealing with them. What annoys me more is that despite basically the entire modern tech industry being in support of- and pushing av1, 99% of the most-modern-compression content I encounter is encoded with h265. There's a good reason for it (h265's initial release was about 5 years earlier) but it still annoys me. I was hoping at least av2 (or whatever it will be called) would be able to get ahead of h266, but I don't see that happening anymore either. Which means were gonna be stuck in the patents quagmire for a long while. Even worse is that parties outside of AOmedia have created an av1 patent pool, despite the explicit reason for av1 being concocted is to not be patent encumbered. Most nastily, they don't go after AOmedia itself but instead sue small(er) parties using av1 to bully them into paying a license. One would expect AOmedia to bring to bear the full brunt of their collective legal departments to scare off the av1 patent leeches, but, so far, not a peep.
saltcured 4y ago
Does anybody know why the earlier JPEG-XR also never got useful browser support? Are we just going to see this repeating over and over with nice general purpose image formats being relegated to individual vendor-centric ecosystems and never providing widespread interop? I find it frustrating how computers have gained so much compute and storage capacity but the web seems to be slipping away as ever more consumer-focused and neutered. Having been there since the beginning, I really expected the web tech and browsers to improve and facilitate scientific data sharing. Not being able to natively decode and display any "exotic" imagery without a bunch of server-side nonsense is frustrating. Today's client machines have so much capability but become totally balkanized when you can't just serve an image tag and display a real scientific image. Instead you either have to hope the users install extra "workstation" tools to display an image after downloading, or deploy absurdly over-engineered "image servers" to do the basic image rendering and ship plain 8-bit JPEGs to the client. Why can't a browser natively provide some basic range-mapping color transfer function tools for high bit-depth images in an image tag? Why can't it provide a pan-zoom viewing mode for high resolution images in an image tag?
Matl 4y ago
> why is Google the scapegoat instead of the entire industry that didn't adopt it? Because on the web Google is 'the industry'. It's not a problem that it was behind a flag, it's a new format after all. The problem is Google did implement it and then removed support without sufficient explanation. Given their market power and the fact they're behind competing standard, it raises a few questions.
IE6 4y ago
Anecdotally but sort of related - we've been using google lighthouse and tools like it to try and optimize our site performance and it was always suggested to use "next gen image formats" but we had the same problem where at the time none of the suggested formats really seemed to have good support.

brookst 4y ago

Yep. This is like teenagers blaming Walmart for their band's lack of success. "If only they had carried our album and featured it on endcaps!"

zinekeller 4y ago
Yep, teenagers like Facebook and Adobe - oh wait. Maybe Google is now flexing its anticompetitive muscles now, isn't it?
- brookst 4y ago
  I must be failing to understand your comment. The people complaining are FSF, and no matter how hard I squint, I cannot see how fair competition could require Google to be the first one to support a standard that literally nobody else supports.
  - zinekeller 4y ago
    > The people complaining are FSF Nope, not just FSF. The Chromium team have prototyped JXL, but removed it initially for unknown reasons (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c183 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...). Engineering teams including but not limited to Adobe, Facebook, Intel and Shopify have complained about its abrupt removal. Chromium developers have subsequently said that it was "due to low interest" (despite piles of messages from engineering teams both in leading companies and small groups saying otherwise). > I cannot see how fair competition could require Google to be the first one to support a standard that literally nobody else supports. First, Adobe products have just included JXL. Second, It's because Google is pushing for AVIF, which was extended from AV1. While it has some advantages (as essentially extended version from AV1), it also has a lot of disadvantages: https://news.ycombinator.com/item?id=35590516 https://news.ycombinator.com/item?id=35590516. No one said to remove AVIF in favor of JXL and in fact there are instances where AVIF is the better choice (animated images due to its interframe support) but instead to support JXL regardless of Google's support of AVIF, and some people have seen it as forcing Google-favored AVIF instead of considering all formats developed (like how WebP was rammed a decade ago).
    - SquareWheel 4y ago
      > but removed it initially for unknown reasons Just an FYI, they gave their reasons in comment #84 of the thread you linked.
- brigade 4y ago
  Adobe didn't support WebP until 2021, they're the poster child for not supporting a format until it's popular enough that they need to add support.
quadrangle 4y ago
There's also the more widespread phenomenon of profitable-enough local businesses blaming Walmart for putting them out of business. How do we evaluate which analogy is appropriate?

adgjlsfhk1 4y ago

Google has 90% of the market. They are the industry.

izacus 4y ago
So they're now forced to maintain every single format someone invents, keep it compatible and security patched forever? Even though even FOSS champion Mozilla wouldn't touch it?
- ksec 4y ago
  >So they're now forced to maintain every single format someone invents, Or they could pick a better format and evaluate it? The question is why the better format here, even though it is the same royalty free ( or patents free in AOM's term ), wasn't picked.
  - mynameisvlad 4y ago
    They could. They could also choose to not to. They could also have done it and their set of reasons doesn’t align with yours. They’re a private company. They can choose to do whatever they want or don’t want to. If they don’t want to support JPEGXL, why should they be forced to do it? If it was such a necessary format, it would have been a competitive disadvantage to not have support and that would have forced their hand, but nobody else supports it either so why should Google be forced to if they (clearly) don’t want to.
    - ksec 4y ago
      They dont have to. But they could also not lie about it. Or lie about do no evil ( I know that is no longer their motto ). Or they could also not lie about WebP, AOM or AMP or everything else about being Good.
      - mynameisvlad 4y ago
        I mean they could do all those things, but, once again, they don’t have to. They don’t have a responsibility to anyone but their shareholders and therefore bottom line.

csdreamer7 4y ago

> No OS appears to have supported it natively either[0]. Not sure what you mean by OS. The link you provided shows that Linux with several GNOME and other tools support JPEG-XL (especially GIMP).

eviks 4y ago
But it's not "native"!

0x_rs 4y ago

>instead of the entire industry that didn't adopt it? Is this a good argument? Nobody is going to adopt something without being natively supported by browsers without ugly js hacks, and when it comes to browser standards it seems to me Google has more leverage than anybody else. Cloudinary has made a lot of posts about JPEG-XL, so you might say they're quite biased towards it, but it also seems to me there is some interest in it by multiple companies [0, 1]. I personally very much doubt webp would be anywhere today without the massive (arguably deceptive) campaigning and double standards it had. 0. https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a... 1. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c16 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

SquareWheel 4y ago
> Nobody is going to adopt something without being natively supported by browsers without ugly js hacks That's fair, but it is worth pointing out that <picture> tags support multiple source formats. I serve some logos and other important images as both .png and .webp. Adding additional lines for avif for jxl seem reasonable - especially if browsers are testing new formats.
mynameisvlad 4y ago
Why should Google be the ones solely responsible for pushing forward file formats? Either you criticize everyone for their parts in not adopting it, or not at all. It seems silly to single out Google and Google alone when nobody else batted an eyelash to try and support the format.
- demonshreder 4y ago
  The majority market share is for Google Chrome, directly and indirectly, thus they are the primary target, while Firefox & Safari will only come next.
jsnell 4y ago
Being supported by some browsers is useless. It needs to be supported by all the major browsers, as shown by webp. Apple did not support JPEG XL, based on past history was unlikely to do so, and despite what you say about Google having the most leverage they have none on Apple. If Apple doesn't want something supported, no iOS browser will support it. And if no iOS browser supports a format, it is not going to be useful in production. I do find it hilarious that all the people who complained about Chrome supporting webp then went on to complain about Chrome not supporting JPEG XL. They're both Google-created formats not widely supported by the ecosystem!

ksec 4y ago

>The reality is that formats have a chicken & egg problem. The same company that gave us WebP. At least Mozilla and Safari did the sane thing and push back against it.

bastawhiz 4y ago
Is your argument that more folks should have pushed back against JPEG XL? Webp was initially released in 2010 when it was the best alternative. JPEG XL came along almost a decade later. The state of image formats is very different.
- zinekeller 4y ago
  No, instead Google should made WebP a proof-of-concept that there are technological advancements that can improve and made a successor of WebP like they've done with QUIC (to HTTP 3), not force-slinging it to everyone. Also, WebP violates the "two independent implementations" standard - at least AVIF can be argued to have two different implementations (due to dav1d).
Spivak 4y ago
Huh? Is there some drama because they all support webp so clearly push didn't come to shove.

kps 4y ago

> [0] https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a... JPEG XL is a general purpose image format, like JPEG and PNG, but improved. WebP is not a serious modern image format; it doesn't even support 16-bit channels. WebP has one specific purpose: web delivery of ephemeral images, leveraging VP8 hardware decoding driven by consumer consumption devices. That's what Google, and web-oriented companies in general, care about. They have no particular interest in general purpose image formats.

Spivak 4y ago
That seems fine then? Browsers are consumer consumption devices. And you have different formats good for other things. That's Apple's philosophy for HEIC.
- webkike 4y ago
  No they are not. They are information delivery devices being co-opted for content consumption
- kps 4y ago
  Although I'm not personally a fan of web apps or Electron, the reality is that browsers are not just consumer consumption devices. And my reading of http://crbug.com/1178058 http://crbug.com/1178058 is that the existence of WebP and AVIF is being used as a justification for removing JPEG XL support.
GoblinSlayer 4y ago
Here have it: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/...

GuB-42 4y ago

The problem is that old PNG and JPEG are good enough for most purposes. They are certainly not as efficient but with todays technology and bandwidth, there is little downside to using JPEG and you know it will be supported everywhere. It is not the case for video. Video is still a huge bandwidth hog, and finding better codecs is worth it, that's why they get better support. Webp is a clever hack as it is essentially a single frame webm video, so if you have webm support, which is worth it, then you can have webp almost for free, JPEG-XL doesn't have that incentive.

kevin_thibedeau 4y ago
Webp max resolution is 16383 x 16383. That is a problem in some applications.
- selcuka 4y ago
  Why any modern image spec should have a maximum resolution is beyond me.
  - jonas21 4y ago
    WebP is based on VP8, which is a video format. Video formats can have maximum resolutions to make it easier to implement hardware decoders.
- flangola7 4y ago
  What application? That's 8x 8K or 32x 4K. Even theoretical futuristic giant displays would not need that.
  - jerryX 4y ago
    Many smartphones now have 200MP e.g. allowing to crop, in astronomy they count in gigapixels ...
    - flangola7 4y ago

eviks 4y ago

There are many reasons, just to list a couple: 1) Chrome is much bigger, so it's much more consequential, so it's valid is a bigger target for criticism 2) It's much easier to performantly support the format on some OS without it being "native", so again, lack of browser support is worse, and thus it's valid it's a bigger target for criticism

unethical_ban 4y ago

You see it's chicken and egg, but then ask why people are upset that the giant chicken with the ability to put out 10,000 eggs a week dropped a feature that was already in their product.

illiarian 4y ago

> https://caniuse.com/jpegxl https://caniuse.com/jpegxl This is kinda how standards are supposed to work: at least two independednt implementations [1], released behind a flag to gather developer and user feedback. However it seems that in the end it went nowhere. [1] See Implementation experience: https://www.w3.org/2021/Process-20211102/#implementation-experience https://www.w3.org/2021/Process-20211102/#implementation-exp... Among other considerations: "are there independent interoperable implementations of the current specification?"

ars 4y ago
It's the "behind a flag" part that is the issue. How are you supposed to get feedback for a feature people can't actually use? It's like when Debian removed a package I use that was not shipped under the rationale that "no one uses it". Obviously no one uses it - you never actually shipped it, you just had the source available if people wanted to compile it.
- illiarian 4y ago
  > How are you supposed to get feedback for a feature people can't actually use? The moment it's out there (that is, not behind a flag), you cannot fix it, update it etc. because people will be relying on the observed behaviour. The hard part is advertising the feature (at the very least to developers) because there are just too many featurs in modern browsers. Edit: for example, Chrome has Origin Trials https://developer.chrome.com/origintrials/#/trials/active https://developer.chrome.com/origintrials/#/trials/active for experimental features.
  - ars 4y ago
    Sure you can - you just do it. You just make the necessary fix. But you do it quickly, within a short time of launching it. Anyone who was able to make use of it within a couple months, will be able to adapt and fix things. Once it's been there for a year, then sure, people rely on it. But there's no reason to take so long.
    - 4y ago

croes 4y ago

It's not really a chicken egg problem. If a browser doesn't support a format as default nobody will use it unless big players like Apple or Google enforce it. If Jpeg XL had been enabled some time without a flag they could claim > There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL but hidden behind a flag there is no way to know. How many users enable experimental features in their browser?

crote 4y ago

Yeah, because it is a new format. You don't immediately publicly release support for an experimental format. Chrome added support for the in-progress version of JPEG XL in April 2021. The core coding specification was finished in March 2022, and the last part of the spec wasn't done until October 2022. Chrome removed it in December 2022, citing a "lack of interest from the ecosystem", despite it having support in most major image editors already. It was a new format which was rapidly being adopted and a lot of major players were very excited about it, but Chrome's removal pretty much killed it due to their dominance in the browser space. At the time of removal, it had better support than HEIC!

pjmlp 4y ago
Similar to how they killed WebGL 2.0 compute, actually.
tourmalinetaco 4y ago
All while they support WebP, which doesn’t appear to have any support anywhere beyond web browsers.
jorvi 4y ago
> At the time of removal, it had better support than HEIC! I don't think I've ever encountered a single JPEG-XL image. Meanwhile I've encountered plenty of HEIC and never encountered a problem in dealing with them. What annoys me more is that despite basically the entire modern tech industry being in support of- and pushing av1, 99% of the most-modern-compression content I encounter is encoded with h265. There's a good reason for it (h265's initial release was about 5 years earlier) but it still annoys me. I was hoping at least av2 (or whatever it will be called) would be able to get ahead of h266, but I don't see that happening anymore either. Which means were gonna be stuck in the patents quagmire for a long while. Even worse is that parties outside of AOmedia have created an av1 patent pool, despite the explicit reason for av1 being concocted is to not be patent encumbered. Most nastily, they don't go after AOmedia itself but instead sue small(er) parties using av1 to bully them into paying a license. One would expect AOmedia to bring to bear the full brunt of their collective legal departments to scare off the av1 patent leeches, but, so far, not a peep.

saltcured 4y ago

Does anybody know why the earlier JPEG-XR also never got useful browser support? Are we just going to see this repeating over and over with nice general purpose image formats being relegated to individual vendor-centric ecosystems and never providing widespread interop? I find it frustrating how computers have gained so much compute and storage capacity but the web seems to be slipping away as ever more consumer-focused and neutered. Having been there since the beginning, I really expected the web tech and browsers to improve and facilitate scientific data sharing. Not being able to natively decode and display any "exotic" imagery without a bunch of server-side nonsense is frustrating. Today's client machines have so much capability but become totally balkanized when you can't just serve an image tag and display a real scientific image. Instead you either have to hope the users install extra "workstation" tools to display an image after downloading, or deploy absurdly over-engineered "image servers" to do the basic image rendering and ship plain 8-bit JPEGs to the client. Why can't a browser natively provide some basic range-mapping color transfer function tools for high bit-depth images in an image tag? Why can't it provide a pan-zoom viewing mode for high resolution images in an image tag?

Matl 4y ago

> why is Google the scapegoat instead of the entire industry that didn't adopt it? Because on the web Google is 'the industry'. It's not a problem that it was behind a flag, it's a new format after all. The problem is Google did implement it and then removed support without sufficient explanation. Given their market power and the fact they're behind competing standard, it raises a few questions.

IE6 4y ago

Anecdotally but sort of related - we've been using google lighthouse and tools like it to try and optimize our site performance and it was always suggested to use "next gen image formats" but we had the same problem where at the time none of the suggested formats really seemed to have good support.