5 ms·

If only Google could be convinced to adopt this marvelous codec... Not looking super positive at the moment: https://issues.chromium.org/issues/40270698 https:

by mikae1 3y ago

If only Google could be convinced to adopt this marvelous codec... Not looking super positive at the moment: https://issues.chromium.org/issues/40270698 https://issues.chromium.org/issues/40270698 https://bugs.chromium.org/p/chromium/issues/detail?id=1451807&no_tracker_redirect=1 https://bugs.chromium.org/p/chromium/issues/detail?id=145180...

pgeorgi 3y ago
All those requests to revert the removal are funny: you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful. Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on...
- silisili 3y ago
  Simply put these offshoots don't really seem to do browser code, and realize how expensive it would be for them to diverge at the core.
- eviks 3y ago
  No, obviously to re-add jxl without a flag
  - pgeorgi 3y ago
    "jxl without a flag" can't be re-added because that was never a thing.
    - albert180 3y ago
      [flagged]
    - deleted 3y ago
      [deleted]
    - elygre 3y ago
      Or (re-add jxl) (without a flag).
    - eviks 3y ago
      It can, that's why you didn't say "re-add jxl", but had to mention the flag, 're-add' has no flag implication, that pedantic attempt to constraint is somehing you've made up, that's not what people want, just read those linked issues
      - pgeorgi 3y ago
        It has a flag implication because jpeg-xl never came without being hidden behind a flag. Nothing was taken away from ordinary users at any point in time. And I suppose the Chrome folks have the telemetry to know how many people set that damn flag.
        jdiff 3y ago
        >"But the plans were on display…” > “On display? I eventually had to go down to the cellar to find them.” > “That’s the display department.” > “With a flashlight.” > “Ah, well, the lights had probably gone.” > “So had the stairs.” > “But look, you found the notice, didn’t you?” > “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
        pgeorgi 3y ago
        I guess you're referring to the idea that the flag made the previous implementation practically non-existent for users. And I agree! But "implement something new!" is a very different demand from "you took that away from us, undo that!"
        jdiff 3y ago
        > No, obviously to re-add jxl without a flag Is asking for the old thing to be re-added, but without the flag that sabotaged it. It is the same as "you took that away from us, undo that!" Removing a flag does not turn it into a magical, mystical new thing that has to be built from scratch. This is silly. The entire point of having flags is to provide a testing platform for code that may one day have the flag removed.
- lonjil 3y ago
  > you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful. Chrome has a neat feature where some flags can be enabled by websites, so that websites can choose to cooperate in testing. They never did this for JXL, but if they re-added JXL behind a flag, they could do so but with such testing enabled. Then they could get real data from websites actually using it, without committing to supporting it if it isn't useful. > Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on... Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year.
  - firsching 3y ago
    > Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year. Interesting!
- deleted 3y ago
  [deleted]
sergioisidoro 3y ago
It's so frustrating how the chromium team is ending up as a gatekeeper of the Internet by pick and choosing what gets developed or not. I recently come across another issue pertaining to the chromium team not budging on their decisions, despite pressure from the community and an RFC backing it up - in my case custom headers in WebSocket handshakes, that are supported by other Javascript runtimes like node and bun, but the chromium maintainer just disagrees with it - https://github.com/whatwg/websockets/issues/16#issuecomment-1961031987 https://github.com/whatwg/websockets/issues/16#issuecomment-...
- hwbunny 3y ago
  Question is for how long. Time to slam the hammer on them.
  - hhh 3y ago
    Why not make a better product than slam some metaphorical hammer?
    - mort96 3y ago
      That's not how this works. Firefox is the closest we have, and realistically the closest we will get to a "better product" than Chromium for the foreseeable future, and it's clearly not enough.
      - KingOfCoders 3y ago
        And Firefox does not support the format. Mozilla is the same political company as everyone else.
      - bombcar 3y ago
        The only hammer at all left is Safari, basically on iPhones only. That hammer is very close to going away; if the EU does force Apple to really open the browsers on the iPhone, everything will be Chrome as far as the eye can see in short order. And then we fully enter the chromE6 phase.
jillesvangurp 3y ago
They didn't "lose interest", their lawyers pulled the emergency brakes. Blame patent holders, not Google. Like Microsoft: https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/. Microsoft could probably be convinced to be reasonable. But there may be a few others. Google actually also holds some patents over this but they've done the right thing and license those patents along with their implementation. To fix this, you'd need to convince Google, and other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.), that these patent holders are not going to insist on being compensated. Other formats are less risky; especially the older ones. Jpeg is fine because it's been out there for so long that any patents applicable to it have long expired. Same with GIF, which once was held up by patents. Png is at this point also fine. If any patents applied at all they will soon have expired as the PNG standard dates back to 1997 and work on it depended on research from the seventies and eighties.
- lifthrasiir 3y ago
  > [...] other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.) [...] Adobe included JPEG XL support to their products and also the DNG specification. So that argument is pretty much dead, no?
  - jillesvangurp 3y ago
    Not that simple. Maybe they struck a deal with a few of the companies or they made a different risk calculation. And of course they have a pretty fierce patent portfolio themselves so there's the notion of them being able to retaliate in kind to some of these companies.
    - lifthrasiir 3y ago
      I don't think that's true (see my other comment for what the patent is really about), but even when it is, Adobe's adoption means that JPEG XL is worth the supposed "risk". And Google does ship a lot of technologies that are clearly patent-encumbered. If the patent is the main concern, they could have answered so because there are enough people wondering about the patent status, but the Chrome team's main reason against JPEG XL was quite different.
Pikamander2 3y ago
Mozilla effectively gave up on it before Google did. https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 It's a real shame, because this is one of those few areas where Firefox could have lead the charge instead of following in Chrome's footsteps. I remember when they first added APNG support and it took Chrome years to catch up, but I guess those days are gone. Oddly enough, Safari is the only major browser that currently supports it despite regularly falling behind on tons of other cutting-edge web standards. https://caniuse.com/jpegxl https://caniuse.com/jpegxl
- JyrkiAlakuijala 3y ago
  I followed Mozilla/Firefox integration closely. I was able to observe enthusiasm from their junior to staff level engineers (linkedin-assisted analysis of the related bugs ;-). However, an engineering director stepped in and locked the discussions because they were in "no new information" stage, and their position has been neutral on JPEG XL, and the integration has not progressed from the nightly builds to the next stage. Ten years ago Mozilla used to have the most prominent image and video compression effort called Daala. They posted inspiring blog posts about their experiments. Some of their work was integrated with Cisco's Thor and On2's/Chrome's VP8/9/10, leading to AV1 and AVIF. Today, I believe, Mozilla has focused away from this research and the ex-Daala researchers have found new roles.
  - lonjil 3y ago
    Daala's and Thor's features were supposed to be integrated into AV1, but in the end, they wanted to finish AV1 as fast as possible, so very little that wasn't in VP10 made it into AV1. I guess it will be in AV2, though.
    - JyrkiAlakuijala 3y ago
      I like to think that there might be an easy way to improve AV2 today — drop the whole keyframe coding and replace it with JPEG XL images as keyframes.
    - 3y ago
deleted 3y ago
[deleted]

by mikae1 3y ago

pgeorgi 3y ago

All those requests to revert the removal are funny: you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful. Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on...

silisili 3y ago
Simply put these offshoots don't really seem to do browser code, and realize how expensive it would be for them to diverge at the core.
eviks 3y ago
No, obviously to re-add jxl without a flag
- pgeorgi 3y ago
  "jxl without a flag" can't be re-added because that was never a thing.
  - albert180 3y ago
    [flagged]
  - deleted 3y ago
    [deleted]
  - elygre 3y ago
    Or (re-add jxl) (without a flag).
  - eviks 3y ago
    It can, that's why you didn't say "re-add jxl", but had to mention the flag, 're-add' has no flag implication, that pedantic attempt to constraint is somehing you've made up, that's not what people want, just read those linked issues
    - pgeorgi 3y ago
      It has a flag implication because jpeg-xl never came without being hidden behind a flag. Nothing was taken away from ordinary users at any point in time. And I suppose the Chrome folks have the telemetry to know how many people set that damn flag.
      - jdiff 3y ago
        >"But the plans were on display…” > “On display? I eventually had to go down to the cellar to find them.” > “That’s the display department.” > “With a flashlight.” > “Ah, well, the lights had probably gone.” > “So had the stairs.” > “But look, you found the notice, didn’t you?” > “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
        pgeorgi 3y ago
        I guess you're referring to the idea that the flag made the previous implementation practically non-existent for users. And I agree! But "implement something new!" is a very different demand from "you took that away from us, undo that!"
        jdiff 3y ago
        > No, obviously to re-add jxl without a flag Is asking for the old thing to be re-added, but without the flag that sabotaged it. It is the same as "you took that away from us, undo that!" Removing a flag does not turn it into a magical, mystical new thing that has to be built from scratch. This is silly. The entire point of having flags is to provide a testing platform for code that may one day have the flag removed.
lonjil 3y ago
> you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful. Chrome has a neat feature where some flags can be enabled by websites, so that websites can choose to cooperate in testing. They never did this for JXL, but if they re-added JXL behind a flag, they could do so but with such testing enabled. Then they could get real data from websites actually using it, without committing to supporting it if it isn't useful. > Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on... Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year.
- firsching 3y ago
  > Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year. Interesting!
deleted 3y ago
[deleted]

sergioisidoro 3y ago

It's so frustrating how the chromium team is ending up as a gatekeeper of the Internet by pick and choosing what gets developed or not. I recently come across another issue pertaining to the chromium team not budging on their decisions, despite pressure from the community and an RFC backing it up - in my case custom headers in WebSocket handshakes, that are supported by other Javascript runtimes like node and bun, but the chromium maintainer just disagrees with it - https://github.com/whatwg/websockets/issues/16#issuecomment-1961031987 https://github.com/whatwg/websockets/issues/16#issuecomment-...

hwbunny 3y ago
Question is for how long. Time to slam the hammer on them.
- hhh 3y ago
  Why not make a better product than slam some metaphorical hammer?
  - mort96 3y ago
    That's not how this works. Firefox is the closest we have, and realistically the closest we will get to a "better product" than Chromium for the foreseeable future, and it's clearly not enough.
    - KingOfCoders 3y ago
      And Firefox does not support the format. Mozilla is the same political company as everyone else.
    - bombcar 3y ago
      The only hammer at all left is Safari, basically on iPhones only. That hammer is very close to going away; if the EU does force Apple to really open the browsers on the iPhone, everything will be Chrome as far as the eye can see in short order. And then we fully enter the chromE6 phase.

jillesvangurp 3y ago

They didn't "lose interest", their lawyers pulled the emergency brakes. Blame patent holders, not Google. Like Microsoft: https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/. Microsoft could probably be convinced to be reasonable. But there may be a few others. Google actually also holds some patents over this but they've done the right thing and license those patents along with their implementation. To fix this, you'd need to convince Google, and other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.), that these patent holders are not going to insist on being compensated. Other formats are less risky; especially the older ones. Jpeg is fine because it's been out there for so long that any patents applicable to it have long expired. Same with GIF, which once was held up by patents. Png is at this point also fine. If any patents applied at all they will soon have expired as the PNG standard dates back to 1997 and work on it depended on research from the seventies and eighties.

lifthrasiir 3y ago
> [...] other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.) [...] Adobe included JPEG XL support to their products and also the DNG specification. So that argument is pretty much dead, no?
- jillesvangurp 3y ago
  Not that simple. Maybe they struck a deal with a few of the companies or they made a different risk calculation. And of course they have a pretty fierce patent portfolio themselves so there's the notion of them being able to retaliate in kind to some of these companies.
  - lifthrasiir 3y ago
    I don't think that's true (see my other comment for what the patent is really about), but even when it is, Adobe's adoption means that JPEG XL is worth the supposed "risk". And Google does ship a lot of technologies that are clearly patent-encumbered. If the patent is the main concern, they could have answered so because there are enough people wondering about the patent status, but the Chrome team's main reason against JPEG XL was quite different.

Pikamander2 3y ago

Mozilla effectively gave up on it before Google did. https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 It's a real shame, because this is one of those few areas where Firefox could have lead the charge instead of following in Chrome's footsteps. I remember when they first added APNG support and it took Chrome years to catch up, but I guess those days are gone. Oddly enough, Safari is the only major browser that currently supports it despite regularly falling behind on tons of other cutting-edge web standards. https://caniuse.com/jpegxl https://caniuse.com/jpegxl

JyrkiAlakuijala 3y ago
I followed Mozilla/Firefox integration closely. I was able to observe enthusiasm from their junior to staff level engineers (linkedin-assisted analysis of the related bugs ;-). However, an engineering director stepped in and locked the discussions because they were in "no new information" stage, and their position has been neutral on JPEG XL, and the integration has not progressed from the nightly builds to the next stage. Ten years ago Mozilla used to have the most prominent image and video compression effort called Daala. They posted inspiring blog posts about their experiments. Some of their work was integrated with Cisco's Thor and On2's/Chrome's VP8/9/10, leading to AV1 and AVIF. Today, I believe, Mozilla has focused away from this research and the ex-Daala researchers have found new roles.
- lonjil 3y ago
  Daala's and Thor's features were supposed to be integrated into AV1, but in the end, they wanted to finish AV1 as fast as possible, so very little that wasn't in VP10 made it into AV1. I guess it will be in AV2, though.
  - JyrkiAlakuijala 3y ago
    I like to think that there might be an easy way to improve AV2 today — drop the whole keyframe coding and replace it with JPEG XL images as keyframes.
  - 3y ago

deleted 3y ago

[deleted]