5 ms·

Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremem

by quikoa 9mo ago

Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.

pixelesque 9mo ago
Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.
- adzm 9mo ago
  And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.
  - deleted 9mo ago
    [deleted]
  - klglrksbjkt 9mo ago
    https://www.google.com/search?q=what+the+old+man+does+is+always+right https://www.google.com/search?q=what+the+old+man+does+is+alw...
    - actionfromafar 9mo ago
      Hahaha perfect! Can't believe I never heard this story before.
    - robocat 9mo ago
      http://hca.gilead.org.il/old_man.html http://hca.gilead.org.il/old_man.html Aviso: http
  - _ache_ 9mo ago
    I can confirm. I found multiple problems in the "official" cjxl encoder back in 2023 contrary to the webp2 (cwp2) implementation where I could not find any bug or error. If the encoder have obvious problems it is not a big deal, but it doesn't bode well for the decoder.
    - adzm 9mo ago
      CVE-2023-0645 in libjxl that year too, and several since
      - rurban 9mo ago
        It's also a horrible API. Will start working on the rust lib then. Hopefully it's better, because I really want to use it.
  - Dylan16807 9mo ago
    Forcing other companies to override them is a way to prove momentum but it's not a good way to prove momentum.
- Dylan16807 9mo ago
  > duplicating largely what AVIF provided That's not a great bar since both of them showed up around the same time. And importantly JXL hits many use cases that AVIF doesn't. > while being written in an unsafe language They put little emphasis on that part when they were rejecting JXL. If they wanted to call for a safer implementation they could have done that.
gcr 9mo ago
Google refused to merge JpegXL as a strategy play to promote AVIF, which was in use by other teams (i think Photos?). Internally, chrome engineers were supportive of jxl but were overridden by leadership.
- zaphar 9mo ago
  Do you have actual sources for this? Because the other people commenting about how the newer library removes most of the concerns explains this better than an unsubstantiated speculation about promoting AVIF.
  - themerone 9mo ago
    If you look at the issue tracker, the creator of Webp killed it because of untrue claims there was no interest or advantages over existing formats. Concerns about the implementation only came up after years of pushback forced google ton reconsider.
    - magicalist 9mo ago
      > If you look at the issue tracker, the creator of Webp killed it because of untrue claims I think for most modern software it's difficult to name the creator, but if you had to for webp, it would be hard to argue that it's anyone but Jyrki Alakuijala, who is in fact one of the co-creators of jpegxl and the person backing up the long-term support of the rust jxl-rs implementation, so I'm not even going to ask for a source here because it's just not true.
      - themerone 9mo ago
        It's been 3 years, I might have people mixed up, but that was the justification at the time.
      - brigade 9mo ago
        AFAIK Jyrki came after WebP was already announced to add lossless support; rather I’d consider Skal the creator inasmuch as it was originally just an image container for VP8 intra. He was working on WebP2 at the time Google rejected JPEG-XL and also was not involved in that decision.

by quikoa 9mo ago

Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.

pixelesque 9mo ago

Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.

adzm 9mo ago
And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.
- deleted 9mo ago
  [deleted]
- klglrksbjkt 9mo ago
  https://www.google.com/search?q=what+the+old+man+does+is+always+right https://www.google.com/search?q=what+the+old+man+does+is+alw...
  - actionfromafar 9mo ago
    Hahaha perfect! Can't believe I never heard this story before.
  - robocat 9mo ago
    http://hca.gilead.org.il/old_man.html http://hca.gilead.org.il/old_man.html Aviso: http
- _ache_ 9mo ago
  I can confirm. I found multiple problems in the "official" cjxl encoder back in 2023 contrary to the webp2 (cwp2) implementation where I could not find any bug or error. If the encoder have obvious problems it is not a big deal, but it doesn't bode well for the decoder.
  - adzm 9mo ago
    CVE-2023-0645 in libjxl that year too, and several since
    - rurban 9mo ago
      It's also a horrible API. Will start working on the rust lib then. Hopefully it's better, because I really want to use it.
- Dylan16807 9mo ago
  Forcing other companies to override them is a way to prove momentum but it's not a good way to prove momentum.
Dylan16807 9mo ago
> duplicating largely what AVIF provided That's not a great bar since both of them showed up around the same time. And importantly JXL hits many use cases that AVIF doesn't. > while being written in an unsafe language They put little emphasis on that part when they were rejecting JXL. If they wanted to call for a safer implementation they could have done that.

gcr 9mo ago

Google refused to merge JpegXL as a strategy play to promote AVIF, which was in use by other teams (i think Photos?). Internally, chrome engineers were supportive of jxl but were overridden by leadership.

zaphar 9mo ago
Do you have actual sources for this? Because the other people commenting about how the newer library removes most of the concerns explains this better than an unsubstantiated speculation about promoting AVIF.
- themerone 9mo ago
  If you look at the issue tracker, the creator of Webp killed it because of untrue claims there was no interest or advantages over existing formats. Concerns about the implementation only came up after years of pushback forced google ton reconsider.
  - magicalist 9mo ago
    > If you look at the issue tracker, the creator of Webp killed it because of untrue claims I think for most modern software it's difficult to name the creator, but if you had to for webp, it would be hard to argue that it's anyone but Jyrki Alakuijala, who is in fact one of the co-creators of jpegxl and the person backing up the long-term support of the rust jxl-rs implementation, so I'm not even going to ask for a source here because it's just not true.
    - themerone 9mo ago
      It's been 3 years, I might have people mixed up, but that was the justification at the time.
    - brigade 9mo ago
      AFAIK Jyrki came after WebP was already announced to add lossless support; rather I’d consider Skal the creator inasmuch as it was originally just an image container for VP8 intra. He was working on WebP2 at the time Google rejected JPEG-XL and also was not involved in that decision.