6 ms·

Mozilla and Google dropping JPEG-XL support because "too much complexity". Software engineers using "too much complexity" as an excuse for something they don't

Mozilla and Google dropping JPEG-XL support because "too much complexity". Software engineers using "too much complexity" as an excuse for something they don't want to do is such a classic move. Browsers are already absurdly complex, and are constantly receiving HTML, CSS and JS features that significantly increase complexity. Are we really to believe that adding support for a certain image format, which is basically as modular as it gets (decode the file into a buffer), is too much complexity? Obviously, this is a case of them showing favoritism toward codecs based on the IP owners of those codecs.

deleted 4y ago
[deleted]
pedrovhb 4y ago
Not to mention the complexity is mostly offloaded to the maintainers of the library itself, not the browser that calls it. I wish Mozilla had gone ahead and enabled it by default in Firefox, as I'd hoped it would. Still salty it didn't happen (yet, at least). It seems like such a clear choice to developers that there's actually people being vocal about it (as evidenced by the sparse but constant stream of e.g. posts on HN about browser image codecs, which is a topic _no one_ finds sexy otherwise), but browser vendors still won't budge. It's weird to see them say "sure it's better, but it's not better enough than the alternatives". There's a large enough discrepancy in my own perception of the merits of jxl and that of the people making choices for browsers that I genuinely wish I understood them, because it feels like I'm missing something. I still convert my pictures to jxl locally and, and the space savings are enough of a reason to go through the trouble of converting - it just seems like a no-brainer that it'd be even more valuable on the web, as bandwidth savings are generally even more important than disk storage, and then there's still the plethora of other features on top of that.
- izacus 4y ago
  The browser developers defacto become the library maintainers since they're now on the hook for any security issue within that library forever. Even if the "real" maintainers go play with something else.
  - skywal_l 4y ago
    Indeed, once you officially support a format and it becomes a standard, you have to support it forever. Sunsetting a feature is not that easy on the web. So if for some reason the maintainer of a library used by the browser drops the ball you are on the hook for anything. And decoding binary data coming from unknown potentially malicious source is full of potential security traps.
    - toastal 4y ago
      Considering <picture> and image() exists and should be seen as a best practice, adding and removing image formats/codecs should have a few less problems than some other libraries, no?
      - eyelidlessness 4y ago
        They provide some resilience, assuming their fallback usage includes multiple formats. Which isn’t a safe assumption, but even granting it, there are other problems with removing a codec. The most obvious being abruptly increasing the bandwidth requirements for all users of the removed codec. Even if that bandwidth is “free”, it can be significant enough to prevent access by end users with slow/spotty connections. Depending on the use case, that can have the consequence of also basically obsoleting the site serving those users. Just as some innovations enable whole new use cases, reverting the innovation can have the opposite effect.
pornel 4y ago
The attempt to provide a second JPEG-XL implementation has stalled. Two independent implementations are the bar for a web standard. AVIF meets it, JPEG-XL does not. There has been enough 3rd party interest to create multiple AV1/AVIF implementations. JPEG-XL has its original team (doing great work), and then… commenters lamenting, but nobody else invested enough to actually to write the code. Browsers' goal is not just to have every benchmark-winning format. They also need to minimize attack surface, risk of bug-compatibility (which is why one and only implementation is not sufficient), and watch out for long-term costs of code size, maintenance, and technical debt. New codecs can be added at any time, but can never be removed. AV1 got in, because video really needed an answer to the looming threat of patented expensive H.265. There was a risk of repeating the pains of H.264 support, and this time without Cisco's licensing loophole. Then AVIF got in, because AV1 was already in. It's that simple.
- hypothesis 4y ago
  This is just WebSQL story all over again, right? “Go redo it from scratch” is the most ridiculous excuse in the book.
  - infogulch 4y ago
    Except they made the right choice with WebSQL. Exposing and securing the entire api surface of sqlite -- from sql syntax to binary compatibility to behavior-altering pragmas -- would have been a compatibility and security nightmare that would make xkcd 1172 look tame by comparison. Exposing a block device instead [1] and layering user-provided sqlite on top of it via WASM [2] is infinitely better than rushing to lock ourselves into a roller coaster that runs straight through the worst compatibility minefield the web has ever seen. [1]: https://news.ycombinator.com/item?id=35165640 https://news.ycombinator.com/item?id=35165640 "Firefox 111.0 enabled Origin private file system access" [2]: https://news.ycombinator.com/item?id=33374402 https://news.ycombinator.com/item?id=33374402 "SQLite in the browser with WASM/JS"
- peppermint_gum 4y ago
  >The attempt to provide a second JPEG-XL implementation has stalled What do you mean by "the attempt"? There are at least three independent decoder implementations: jxl-oxide (Rust): https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide J40 (C): https://github.com/lifthrasiir/j40 https://github.com/lifthrasiir/j40 jxlatte (Java): https://github.com/thebombzen/jxlatte https://github.com/thebombzen/jxlatte None of them is feature complete, but it's because each of them is a hobby, single-person project. You're making it sound like some billion-dollar company tried to implement JPEG XL and failed, because it's too complex or something. However, it should be noted that those independent implementations, despite being hobby projects, helped to iron-out some minor issues in the standard. >Then AVIF got in, because AV1 was already in. AVIF uses its own container format that had to be implemented. Implementing AV1 does not give you AVIF support for free.
ksec 4y ago
>Obviously, this is a case of them showing favoritism toward codecs based on the IP owners of those codecs. I am sorry it is hard for me to not take a jab at this considering their codec is patent free so their should be zero IP owners. /s Anyway JPEG XL is a miniture project physically. A compressed wasm binary is around 175 kB. I don't think complexity is an issue there. [1] [1] https://twitter.com/jyzg/status/1633504595094773765 https://twitter.com/jyzg/status/1633504595094773765
- scorpio241 4y ago
  This is a battle for future default image codec: open standard vs nearly proprietary controlled by a few corporations - https://en.wikipedia.org/wiki/Alliance_for_Open_Media https://en.wikipedia.org/wiki/Alliance_for_Open_Media : > The governing members of the Alliance for Open Media are Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent. For example with defensive license termination: they can sue you, but if you try to sue them you have to rip off AVIF from all your products: https://aomedia.org/license/patent-license/ https://aomedia.org/license/patent-license/ >Defensive Termination. If any Licensee, its Affiliates, or its agents initiates patent litigation or files, maintains, or voluntarily participates in a lawsuit against another entity or any person asserting that any Implementation infringes Necessary Claims, any patent licenses granted under this License directly to the Licensee are immediately terminated as of the date of the initiation of action unless 1) that suit was in response to a corresponding suit regarding an Implementation first brought against an initiating entity, or 2) that suit was brought to enforce the terms of this License (including intervention in a third-party action by a Licensee).
  - jonsneyers 4y ago
    Defensive license termination is actually a good thing. It is how you can keep a codec royalty-free. Without defensive termination, it is way too easy in the current patent system for patent trolls to make bogus claims and bully companies into paying them royalties. JPEG XL also has defensive termination clauses, and so do the Apache 2.0 and GPL v3 FOSS licenses. AOM has noble goals: royalty-free codecs for the web. JXL is also a royalty-free codec that is very well suited for the web (as well as many other use cases for still images). There is no reason why we can't just have both supported by browsers.

deleted 4y ago

[deleted]

pedrovhb 4y ago

Not to mention the complexity is mostly offloaded to the maintainers of the library itself, not the browser that calls it. I wish Mozilla had gone ahead and enabled it by default in Firefox, as I'd hoped it would. Still salty it didn't happen (yet, at least). It seems like such a clear choice to developers that there's actually people being vocal about it (as evidenced by the sparse but constant stream of e.g. posts on HN about browser image codecs, which is a topic _no one_ finds sexy otherwise), but browser vendors still won't budge. It's weird to see them say "sure it's better, but it's not better enough than the alternatives". There's a large enough discrepancy in my own perception of the merits of jxl and that of the people making choices for browsers that I genuinely wish I understood them, because it feels like I'm missing something. I still convert my pictures to jxl locally and, and the space savings are enough of a reason to go through the trouble of converting - it just seems like a no-brainer that it'd be even more valuable on the web, as bandwidth savings are generally even more important than disk storage, and then there's still the plethora of other features on top of that.

izacus 4y ago
The browser developers defacto become the library maintainers since they're now on the hook for any security issue within that library forever. Even if the "real" maintainers go play with something else.
- skywal_l 4y ago
  Indeed, once you officially support a format and it becomes a standard, you have to support it forever. Sunsetting a feature is not that easy on the web. So if for some reason the maintainer of a library used by the browser drops the ball you are on the hook for anything. And decoding binary data coming from unknown potentially malicious source is full of potential security traps.
  - toastal 4y ago
    Considering <picture> and image() exists and should be seen as a best practice, adding and removing image formats/codecs should have a few less problems than some other libraries, no?
    - eyelidlessness 4y ago
      They provide some resilience, assuming their fallback usage includes multiple formats. Which isn’t a safe assumption, but even granting it, there are other problems with removing a codec. The most obvious being abruptly increasing the bandwidth requirements for all users of the removed codec. Even if that bandwidth is “free”, it can be significant enough to prevent access by end users with slow/spotty connections. Depending on the use case, that can have the consequence of also basically obsoleting the site serving those users. Just as some innovations enable whole new use cases, reverting the innovation can have the opposite effect.

pornel 4y ago

The attempt to provide a second JPEG-XL implementation has stalled. Two independent implementations are the bar for a web standard. AVIF meets it, JPEG-XL does not. There has been enough 3rd party interest to create multiple AV1/AVIF implementations. JPEG-XL has its original team (doing great work), and then… commenters lamenting, but nobody else invested enough to actually to write the code. Browsers' goal is not just to have every benchmark-winning format. They also need to minimize attack surface, risk of bug-compatibility (which is why one and only implementation is not sufficient), and watch out for long-term costs of code size, maintenance, and technical debt. New codecs can be added at any time, but can never be removed. AV1 got in, because video really needed an answer to the looming threat of patented expensive H.265. There was a risk of repeating the pains of H.264 support, and this time without Cisco's licensing loophole. Then AVIF got in, because AV1 was already in. It's that simple.

hypothesis 4y ago
This is just WebSQL story all over again, right? “Go redo it from scratch” is the most ridiculous excuse in the book.
- infogulch 4y ago
  Except they made the right choice with WebSQL. Exposing and securing the entire api surface of sqlite -- from sql syntax to binary compatibility to behavior-altering pragmas -- would have been a compatibility and security nightmare that would make xkcd 1172 look tame by comparison. Exposing a block device instead [1] and layering user-provided sqlite on top of it via WASM [2] is infinitely better than rushing to lock ourselves into a roller coaster that runs straight through the worst compatibility minefield the web has ever seen. [1]: https://news.ycombinator.com/item?id=35165640 https://news.ycombinator.com/item?id=35165640 "Firefox 111.0 enabled Origin private file system access" [2]: https://news.ycombinator.com/item?id=33374402 https://news.ycombinator.com/item?id=33374402 "SQLite in the browser with WASM/JS"
peppermint_gum 4y ago
>The attempt to provide a second JPEG-XL implementation has stalled What do you mean by "the attempt"? There are at least three independent decoder implementations: jxl-oxide (Rust): https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide J40 (C): https://github.com/lifthrasiir/j40 https://github.com/lifthrasiir/j40 jxlatte (Java): https://github.com/thebombzen/jxlatte https://github.com/thebombzen/jxlatte None of them is feature complete, but it's because each of them is a hobby, single-person project. You're making it sound like some billion-dollar company tried to implement JPEG XL and failed, because it's too complex or something. However, it should be noted that those independent implementations, despite being hobby projects, helped to iron-out some minor issues in the standard. >Then AVIF got in, because AV1 was already in. AVIF uses its own container format that had to be implemented. Implementing AV1 does not give you AVIF support for free.

ksec 4y ago

>Obviously, this is a case of them showing favoritism toward codecs based on the IP owners of those codecs. I am sorry it is hard for me to not take a jab at this considering their codec is patent free so their should be zero IP owners. /s Anyway JPEG XL is a miniture project physically. A compressed wasm binary is around 175 kB. I don't think complexity is an issue there. [1] [1] https://twitter.com/jyzg/status/1633504595094773765 https://twitter.com/jyzg/status/1633504595094773765

scorpio241 4y ago
This is a battle for future default image codec: open standard vs nearly proprietary controlled by a few corporations - https://en.wikipedia.org/wiki/Alliance_for_Open_Media https://en.wikipedia.org/wiki/Alliance_for_Open_Media : > The governing members of the Alliance for Open Media are Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent. For example with defensive license termination: they can sue you, but if you try to sue them you have to rip off AVIF from all your products: https://aomedia.org/license/patent-license/ https://aomedia.org/license/patent-license/ >Defensive Termination. If any Licensee, its Affiliates, or its agents initiates patent litigation or files, maintains, or voluntarily participates in a lawsuit against another entity or any person asserting that any Implementation infringes Necessary Claims, any patent licenses granted under this License directly to the Licensee are immediately terminated as of the date of the initiation of action unless 1) that suit was in response to a corresponding suit regarding an Implementation first brought against an initiating entity, or 2) that suit was brought to enforce the terms of this License (including intervention in a third-party action by a Licensee).
- jonsneyers 4y ago
  Defensive license termination is actually a good thing. It is how you can keep a codec royalty-free. Without defensive termination, it is way too easy in the current patent system for patent trolls to make bogus claims and bully companies into paying them royalties. JPEG XL also has defensive termination clauses, and so do the Apache 2.0 and GPL v3 FOSS licenses. AOM has noble goals: royalty-free codecs for the web. JXL is also a royalty-free codec that is very well suited for the web (as well as many other use cases for still images). There is no reason why we can't just have both supported by browsers.