5 ms·

What's up with this JPEG XL cult in hacker news? I think the Chrome team pretty much handled this in the best way possible. They put everything in public and al

What's up with this JPEG XL cult in hacker news? I think the Chrome team pretty much handled this in the best way possible. They put everything in public and allowed anyone to comment on their main thread. They responded to lot of the comments. They seems to have their best intention in having JPEG XL implementation in chrome but the team decided it's not worth it, which is a valid decision for someone doing ROI analysis, after all engineers specialising in this are not cheap. It's like everyone is hinting at some conspiracy by Google here that is not there as they spent time in the spec and wanted to promote this. Even I think the incremental 20% gain of JPEG XL is probably not worth the security risk and increased maintenance. JPEG decoders had been targeted so many times in the past even though it had been audited by best security folks.

ksec 4y ago
I am probably the first few if not the first to put JPEG XL on HN's radar. I am definitely not in an JPEG XL Cult. Although I do dislike Google. I am simply a supporter of Better Tech. (And I am already omitting WebP hate here. ) And I suspect a lot of us are. And IMO neither WebP nor AVIF are better than JPEG XL. Had Google actually posted a thorough analysis, as they stated that JPEG XL is not better or even inferior to AVIF, and suggest they decide not to go with it. It would have been fine. ( I may disagree with their take, but at least you can see it from their POV ). Not only did they not do that, they provided the Data with out of date version of JPEG XL [1] and a set of test that does not represent the actual internet usage. Compared to [2], where JPEG XL is surprisingly better when they wont expected. So if, a) everything JPEG XL released and tested were true, and truly better than AVIF, then b) Why isn't Google supporting the better Image codec? I am also perfectly fine with Google saying, I dont like it. I hate it because It is not AOM even if JPEG XL is better. Fine. Chrome is Google's browser. Do what ever you want with it. Just dont ever come out again and say everything you do is better for the Web. [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html [2] https://twitter.com/jonsneyers/status/1563442356493230080 https://twitter.com/jonsneyers/status/1563442356493230080
- deleted 4y ago
  [deleted]
regulation_d 4y ago
I know essentially zero about this space, but I would almost argue categorically that 20% is not "incremental".
- YetAnotherNick 4y ago
  Then why haven't everyone switched to webp from png/jpeg which gave >25% gain over jpeg and supported by chrome from 12 years? For better or worse, no one wants to sacrifice compatibility for 20% gain.
  - F3nd0 4y ago
    Because WebP does not offer a >25% improvement. As far as I know, it is only better than JPEG in some cases, and then seldom by that much. [1] And of course, this is only when you compress an image lossily. If you try to recompress an already-lossy JPEG as a WebP, it will suffer even more quality loss in the process. (And if you try to recompress it losslessly, the resulting WebP will be bigger.) JPEG XL lets you recompress an existing lossy JPEG losslessly, saving you 20% in the process. This is something that other formats like WebP or AVIF do not and can not offer. [1]: https://siipo.la/blog/is-webp-really-better-than-jpeg https://siipo.la/blog/is-webp-really-better-than-jpeg
    - YetAnotherNick 4y ago
      Even the site you pointed to show average 18% decrease in size compared to best but slow jpeg encoder. "JPEG XL lets you recompress an existing lossy JPEG losslessly” This is such a niche usecase. Who cares about bit more lossy compression for an already lossy compressed file.
      - lifthrasiir 4y ago
        I guess you have a misunderstanding here, it's a lossless compression of an already lossily compressed file (which had used suboptimal coding methods). You will get a bit-perfect original JPEG file when you decompress a recompressed JPEG XL file. No additional compression artifact there.
masklinn 4y ago
> What's up with this JPEG XL cult in hacker news? I'm not sure it's on HN specifically. There seems to be a JXL cult, and like butters they flock to any mention. And in the same vein, they seem to inject large amounts of copium when reality doesn't go their way.
- lifthrasiir 4y ago
  I don't like them too, but you do sound like naysayers to Rust back when it was less mature, don't you? Having cults doesn't mean anything, just stick to verifiable facts and logical reasoning regardless of them.
  - YetAnotherNick 4y ago
    What’s the issue with being naysayer to rust? As long as somoneone is not actively harming rust community or spamming the community, it is fine and Rust is free to do what they want. On the other hand, look at the JPEG XL google group and see all kind of demanding and spammy messages asking the same questions literally dozens of times. > Having cults doesn't mean anything It does mean that they are the worst person to talk to.
    - lifthrasiir 4y ago
      > What’s the issue with being naysayer to rust? There is no issue per se, but I'm referring to a certain group of people who didn't like Rust because they thought many if not most Rust users are in a cult. This observation was partly true and partly false; I've previously described what went possibly wrong [1]. Even at that time some people, no matter they like or don't like Rust, tried to continue a constructive discussion and I'm asking the same here. Your claim should not vary by the presence or lack of the quote-unquote cult. [1] https://news.ycombinator.com/item?id=32802291 https://news.ycombinator.com/item?id=32802291
    - jonsneyers 4y ago
      Which google group are you referring to? The bugtracker? Some of the comments there are useful imo, e.g. when image experts from various companies bring their views. Others are basically just "+1", which is better done by just starring the issue. But it does look like most people who did not have anything useful to add did indeed do exactly that, comparing the number of comments to the number of stars.
jsnell 4y ago
HN loves, in the aggregate, to hate on Google. So Chrome removing support for an image format is a good opportunity come up with inane conspiracy theories. Repeatedly. The good thing about a conspiracy theory is that facts don't matter. JPEG XL being a primarily Google-created format in the first place? The format being dead in the water on the web without support from Apple/Safari, which was never forthcoming? Nobody wanting a repeat of web? Irrelevant, you can just pretend that this is actually a format that every other browser supports.
- dmitriid 4y ago
  > The format being dead in the water on the web without support from Apple/Safari, which was never forthcoming? Never stopped Google from pushing its own codecs. Often without even a stable version of the spec for years. And often threatening third party ecosystem with "implement this or else".
lifthrasiir 4y ago
There is an interesting cult I only realized after this affair, namely a group of WebP haters. Apparently there are a lot of them but weren't visible until JPEG XL is seen as a "solution" to WebP, and many of them became a vocal supporter for JPEG XL at any cost. So that's a big part of the cult. Another part is probably a growing opposition to Google and Chrome. I had to explain again and again that JPEG XL was also jointly developed by Google (Research Zurich) and Cloudinary, but you can still reasonably argue that Chrome aligns better with Google's own interest than Google Research. And if you apply the same stringent criteria to AVIF, AVIF doesn't stand well either---it would have made zero positive difference if AVIF was deployed this year and not 2 years ago, and libavif is not that small. As AVIF and JPEG XL have their pros and cons when compared to each other, this alone can be seen suspicious enough from outsiders. Keep in mind that Chrome is now the Web Browser so there are a lot more to expect from them, like or not.
- chungy 4y ago
  I'm probably part of the group you'd call "WebP haters", especially if you look at my comment history[1]. I would rather describe myself as extremely disappointed in WebP. It's a clear win over PNG in the lossless use case. I have encountered a few outliers where a PNG results in a smaller file size than lossless WebP, but they are sufficiently rare to not worry about it. It also excludes the image sizes too large for WebP to handle (my system has a mix of WebP-lossless and PNG files for that reason). For lossy use cases, however, WebP is not a win over JPEG if you are concerned about anything other than file size. MozJPEG closes the encoding size gap rather significantly and WebP-lossy's origins in VP8 intraframes and limiting itself to 4:2:0 subsampling is just... awful. I never use WebP-lossy. It gains nothing from JPEG and comes out as inferior in basically all scenarios. I don't view JPEG XL as a "solution" to WebP, but rather as a solution to JPEG. WebP was never competitive in the first place. [1] In particular: https://news.ycombinator.com/item?id=33448714 https://news.ycombinator.com/item?id=33448714
  - JyrkiAlakuijala 4y ago
    I'm the author of lossless WebP. From my personal point of view I agree, the benefits of WebP lossy were too marginal to balance off its weaknesses (I have observed somewhat unpredictable quality, tendency to blurring, occasional reduction of saturation, and limitation to 420). I like MozJPEG in the lower quality range, but I'm disappointed with it in the medium-to-high quality range (q85-100) -- there guetzli or jpegli does quite a bit better. Often MozJPEG appears worse than libjpeg-turbo in the highest quality whereas both guetzli and jpegli are substantially (~35 %) better.
jonsneyers 4y ago
Some people don't like Google or Chrome in general, for various reasons (valid or not), and they'll use any opportunity to criticize them. JPEG XL was made in the JPEG committee and the two main proponents were Google and Cloudinary. So it's insane to say that Google in general would be opposed to JPEG XL. This was not a Google team that was part of the Chrome team though. The way the Chrome team has handled this was not "the best way possible" in my opinion. They first made a decision, and then a month later they showed the data that lead to it (that was one week ago). This data was created by the AVIF team. They did invite anyone to provide feedback on this data, but they did not wait for this feedback to execute on the decision. I don't think this is the best way possible to handle this. A better way would be to first provide data, then wait for feedback, allow all sides to provide their input, have an open and honest discussion involving all stakeholders and experts, and then make a decision. That would be a better ordering of steps. I agree though that this is not some conspiracy by Google. It is just a difficult technical decision to make, and they're currently making the wrong decision in my opinion, but this is something that has to be motivated technically, not emotionally or politically.
mike_hearn 4y ago
Proposal: some of the criticism may be motivated primarily by the meta-level issue rather than the object-level issue, viz. what this kerfuffle says about HTML5 and web technology in general. The web has many positive aspects but modularity isn't one of them. HTML5 has turned into an unfocused attempt to specify a whole computer from bottom to top - everything from a [virtual] CPU, to programming languages, graphics stacks, text rendering, UI toolkits, MIDI, sockets, storage, Bluetooth, USB and more. Unlike other operating systems, the resulting Chrome pseudo-OS has nearly no extensibility. Attempts to use WebAssembly to hack around this yield mixed results at best given the problems of needing to constantly re-download the modules (cache segmentation), needing to re-JITC the modules and inability to share code (process isolation). Images are a core part of the web's functionality, they were literally one of the first features ever added to HTML. The fact that new image formats can't be added for code maintenance reasons, even when having clearly unique features and interest from major companies, worryingly suggests that the web platform may be heading towards a form of technical bankruptcy. HTML has support for obscure features virtually no web sites will ever use like MIDI or USB support, whilst an upgrade to a core feature that every website uses (except HN of course!) apparently cannot be done any longer. It means implementing a complete yet non-extensible OS stack from top to bottom is a task too large for even the world's largest and richest corporations. In the beginning, the web's architects realized and understood that it wasn't feasible for browsers to implement everything you might want to embed in a web page. The plugins API was an early addition to the platform as a consequence. When it was deprecated, the stated reasoning was as follows: https://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html https://blog.chromium.org/2014/11/the-final-countdown-for-np... "Last September we announced our plan to remove NPAPI support from Chrome, a change that will improve Chrome’s security, speed, and stability as well as reduce complexity in the code base" At the time this sounded wise. But since then tens of millions of lines of code have been added to Chrome (almost all C++) so "reducing complexity in the codebase" seems like a hard argument to make with hindsight. Browsers were capable of running plugins inside their process sandboxes and exploits in Blink are found regularly, so it's not really clear that it made much security difference either. So maybe that's one reason it's getting such a reaction. This JXL incident isn't just about JXL. It's about what it implies for the future. Who will even bother researching new image codecs now, if even Google itself can't get a better codec into the web? It may be time to start thinking about what alternative designs to the web might look like, with a strong focus on modularity and extensibility whilst still taking into account everything that was learned over the past 30 years. I have some ideas already but haven't written them up yet.

ksec 4y ago

I am probably the first few if not the first to put JPEG XL on HN's radar. I am definitely not in an JPEG XL Cult. Although I do dislike Google. I am simply a supporter of Better Tech. (And I am already omitting WebP hate here. ) And I suspect a lot of us are. And IMO neither WebP nor AVIF are better than JPEG XL. Had Google actually posted a thorough analysis, as they stated that JPEG XL is not better or even inferior to AVIF, and suggest they decide not to go with it. It would have been fine. ( I may disagree with their take, but at least you can see it from their POV ). Not only did they not do that, they provided the Data with out of date version of JPEG XL [1] and a set of test that does not represent the actual internet usage. Compared to [2], where JPEG XL is surprisingly better when they wont expected. So if, a) everything JPEG XL released and tested were true, and truly better than AVIF, then b) Why isn't Google supporting the better Image codec? I am also perfectly fine with Google saying, I dont like it. I hate it because It is not AOM even if JPEG XL is better. Fine. Chrome is Google's browser. Do what ever you want with it. Just dont ever come out again and say everything you do is better for the Web. [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html [2] https://twitter.com/jonsneyers/status/1563442356493230080 https://twitter.com/jonsneyers/status/1563442356493230080

deleted 4y ago
[deleted]

regulation_d 4y ago

I know essentially zero about this space, but I would almost argue categorically that 20% is not "incremental".

YetAnotherNick 4y ago
Then why haven't everyone switched to webp from png/jpeg which gave >25% gain over jpeg and supported by chrome from 12 years? For better or worse, no one wants to sacrifice compatibility for 20% gain.
- F3nd0 4y ago
  Because WebP does not offer a >25% improvement. As far as I know, it is only better than JPEG in some cases, and then seldom by that much. [1] And of course, this is only when you compress an image lossily. If you try to recompress an already-lossy JPEG as a WebP, it will suffer even more quality loss in the process. (And if you try to recompress it losslessly, the resulting WebP will be bigger.) JPEG XL lets you recompress an existing lossy JPEG losslessly, saving you 20% in the process. This is something that other formats like WebP or AVIF do not and can not offer. [1]: https://siipo.la/blog/is-webp-really-better-than-jpeg https://siipo.la/blog/is-webp-really-better-than-jpeg
  - YetAnotherNick 4y ago
    Even the site you pointed to show average 18% decrease in size compared to best but slow jpeg encoder. "JPEG XL lets you recompress an existing lossy JPEG losslessly” This is such a niche usecase. Who cares about bit more lossy compression for an already lossy compressed file.
    - lifthrasiir 4y ago
      I guess you have a misunderstanding here, it's a lossless compression of an already lossily compressed file (which had used suboptimal coding methods). You will get a bit-perfect original JPEG file when you decompress a recompressed JPEG XL file. No additional compression artifact there.

masklinn 4y ago

> What's up with this JPEG XL cult in hacker news? I'm not sure it's on HN specifically. There seems to be a JXL cult, and like butters they flock to any mention. And in the same vein, they seem to inject large amounts of copium when reality doesn't go their way.

lifthrasiir 4y ago
I don't like them too, but you do sound like naysayers to Rust back when it was less mature, don't you? Having cults doesn't mean anything, just stick to verifiable facts and logical reasoning regardless of them.
- YetAnotherNick 4y ago
  What’s the issue with being naysayer to rust? As long as somoneone is not actively harming rust community or spamming the community, it is fine and Rust is free to do what they want. On the other hand, look at the JPEG XL google group and see all kind of demanding and spammy messages asking the same questions literally dozens of times. > Having cults doesn't mean anything It does mean that they are the worst person to talk to.
  - lifthrasiir 4y ago
    > What’s the issue with being naysayer to rust? There is no issue per se, but I'm referring to a certain group of people who didn't like Rust because they thought many if not most Rust users are in a cult. This observation was partly true and partly false; I've previously described what went possibly wrong [1]. Even at that time some people, no matter they like or don't like Rust, tried to continue a constructive discussion and I'm asking the same here. Your claim should not vary by the presence or lack of the quote-unquote cult. [1] https://news.ycombinator.com/item?id=32802291 https://news.ycombinator.com/item?id=32802291
  - jonsneyers 4y ago
    Which google group are you referring to? The bugtracker? Some of the comments there are useful imo, e.g. when image experts from various companies bring their views. Others are basically just "+1", which is better done by just starring the issue. But it does look like most people who did not have anything useful to add did indeed do exactly that, comparing the number of comments to the number of stars.

jsnell 4y ago

HN loves, in the aggregate, to hate on Google. So Chrome removing support for an image format is a good opportunity come up with inane conspiracy theories. Repeatedly. The good thing about a conspiracy theory is that facts don't matter. JPEG XL being a primarily Google-created format in the first place? The format being dead in the water on the web without support from Apple/Safari, which was never forthcoming? Nobody wanting a repeat of web? Irrelevant, you can just pretend that this is actually a format that every other browser supports.

dmitriid 4y ago
> The format being dead in the water on the web without support from Apple/Safari, which was never forthcoming? Never stopped Google from pushing its own codecs. Often without even a stable version of the spec for years. And often threatening third party ecosystem with "implement this or else".

lifthrasiir 4y ago

There is an interesting cult I only realized after this affair, namely a group of WebP haters. Apparently there are a lot of them but weren't visible until JPEG XL is seen as a "solution" to WebP, and many of them became a vocal supporter for JPEG XL at any cost. So that's a big part of the cult. Another part is probably a growing opposition to Google and Chrome. I had to explain again and again that JPEG XL was also jointly developed by Google (Research Zurich) and Cloudinary, but you can still reasonably argue that Chrome aligns better with Google's own interest than Google Research. And if you apply the same stringent criteria to AVIF, AVIF doesn't stand well either---it would have made zero positive difference if AVIF was deployed this year and not 2 years ago, and libavif is not that small. As AVIF and JPEG XL have their pros and cons when compared to each other, this alone can be seen suspicious enough from outsiders. Keep in mind that Chrome is now the Web Browser so there are a lot more to expect from them, like or not.

chungy 4y ago
I'm probably part of the group you'd call "WebP haters", especially if you look at my comment history[1]. I would rather describe myself as extremely disappointed in WebP. It's a clear win over PNG in the lossless use case. I have encountered a few outliers where a PNG results in a smaller file size than lossless WebP, but they are sufficiently rare to not worry about it. It also excludes the image sizes too large for WebP to handle (my system has a mix of WebP-lossless and PNG files for that reason). For lossy use cases, however, WebP is not a win over JPEG if you are concerned about anything other than file size. MozJPEG closes the encoding size gap rather significantly and WebP-lossy's origins in VP8 intraframes and limiting itself to 4:2:0 subsampling is just... awful. I never use WebP-lossy. It gains nothing from JPEG and comes out as inferior in basically all scenarios. I don't view JPEG XL as a "solution" to WebP, but rather as a solution to JPEG. WebP was never competitive in the first place. [1] In particular: https://news.ycombinator.com/item?id=33448714 https://news.ycombinator.com/item?id=33448714
- JyrkiAlakuijala 4y ago
  I'm the author of lossless WebP. From my personal point of view I agree, the benefits of WebP lossy were too marginal to balance off its weaknesses (I have observed somewhat unpredictable quality, tendency to blurring, occasional reduction of saturation, and limitation to 420). I like MozJPEG in the lower quality range, but I'm disappointed with it in the medium-to-high quality range (q85-100) -- there guetzli or jpegli does quite a bit better. Often MozJPEG appears worse than libjpeg-turbo in the highest quality whereas both guetzli and jpegli are substantially (~35 %) better.

jonsneyers 4y ago

Some people don't like Google or Chrome in general, for various reasons (valid or not), and they'll use any opportunity to criticize them. JPEG XL was made in the JPEG committee and the two main proponents were Google and Cloudinary. So it's insane to say that Google in general would be opposed to JPEG XL. This was not a Google team that was part of the Chrome team though. The way the Chrome team has handled this was not "the best way possible" in my opinion. They first made a decision, and then a month later they showed the data that lead to it (that was one week ago). This data was created by the AVIF team. They did invite anyone to provide feedback on this data, but they did not wait for this feedback to execute on the decision. I don't think this is the best way possible to handle this. A better way would be to first provide data, then wait for feedback, allow all sides to provide their input, have an open and honest discussion involving all stakeholders and experts, and then make a decision. That would be a better ordering of steps. I agree though that this is not some conspiracy by Google. It is just a difficult technical decision to make, and they're currently making the wrong decision in my opinion, but this is something that has to be motivated technically, not emotionally or politically.

mike_hearn 4y ago

Proposal: some of the criticism may be motivated primarily by the meta-level issue rather than the object-level issue, viz. what this kerfuffle says about HTML5 and web technology in general. The web has many positive aspects but modularity isn't one of them. HTML5 has turned into an unfocused attempt to specify a whole computer from bottom to top - everything from a [virtual] CPU, to programming languages, graphics stacks, text rendering, UI toolkits, MIDI, sockets, storage, Bluetooth, USB and more. Unlike other operating systems, the resulting Chrome pseudo-OS has nearly no extensibility. Attempts to use WebAssembly to hack around this yield mixed results at best given the problems of needing to constantly re-download the modules (cache segmentation), needing to re-JITC the modules and inability to share code (process isolation). Images are a core part of the web's functionality, they were literally one of the first features ever added to HTML. The fact that new image formats can't be added for code maintenance reasons, even when having clearly unique features and interest from major companies, worryingly suggests that the web platform may be heading towards a form of technical bankruptcy. HTML has support for obscure features virtually no web sites will ever use like MIDI or USB support, whilst an upgrade to a core feature that every website uses (except HN of course!) apparently cannot be done any longer. It means implementing a complete yet non-extensible OS stack from top to bottom is a task too large for even the world's largest and richest corporations. In the beginning, the web's architects realized and understood that it wasn't feasible for browsers to implement everything you might want to embed in a web page. The plugins API was an early addition to the platform as a consequence. When it was deprecated, the stated reasoning was as follows: https://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html https://blog.chromium.org/2014/11/the-final-countdown-for-np... "Last September we announced our plan to remove NPAPI support from Chrome, a change that will improve Chrome’s security, speed, and stability as well as reduce complexity in the code base" At the time this sounded wise. But since then tens of millions of lines of code have been added to Chrome (almost all C++) so "reducing complexity in the codebase" seems like a hard argument to make with hindsight. Browsers were capable of running plugins inside their process sandboxes and exploits in Blink are found regularly, so it's not really clear that it made much security difference either. So maybe that's one reason it's getting such a reaction. This JXL incident isn't just about JXL. It's about what it implies for the future. Who will even bother researching new image codecs now, if even Google itself can't get a better codec into the web? It may be time to start thinking about what alternative designs to the web might look like, with a strong focus on modularity and extensibility whilst still taking into account everything that was learned over the past 30 years. I have some ideas already but haven't written them up yet.