6 ms·

JPEG XL and Google's War Against It

77 points by OuterVale 2y ago

jdashg 2y ago
It's superficial analysis to assume that when Mozilla agrees with Google, it's about money. That's merely correlation. Other people and organizations can disagree with your arguments in ways that you don't think are logical or sound, but that doesn't mean they aren't just based on different weights and criteria. It's not useful to assume the decision criteria, because it becomes too easy to declare yourself right yet be confused why other people don't recognize it. Never simply attribute to malice what can be explained by incompetence, but also never simply attribute to incompetence what can be explained by disagreement.
- barfbagginus 2y ago
  The argument is that pressuring Mozilla is a valid second line of attack, on top of pressuring Google. That seems fairly benign, given that Google and Mozilla both have power in the browser ecosystem. I don't see any assumptions about Mozilla's motive, or think it would be relevant to assume motive one way or another. The assumption is that Mozilla has power to help fuel JPEG XL adoption, so that pressure wouldn't simply be wasted. Now, I'm not sure it has this power given its 3% browser market share. This might invalidate the particular argument. That said, there are many valid reasons to give Mozilla execs grief, and many valid reasons to work to deconstruct Mozilla's leadership. So I don't mind if people do it over JPEG-XL, even if Mozilla's had zero power to affect JPEG-XL.
  - kodabbb 2y ago
    this is so toxic it's not even funny
    - barfbagginus 2y ago
      It's perfectly fine to be toxic and unfunny towards Mozilla's C-suite, kodabbb
pornel 2y ago
The article has a warped timeline of WebP, with incorrect speculation, and missing key points. WebP has been created in the rush of wild optimism after Google has freed the VP8 video format (WebM). VP8 has been strategically important for them (and YouTube), because before then Web video has been at mercy of Flash, Silverlight, and threatened by H.264 patent royalties. The WebP format has been rushed. It didn't go through a usual standards process. The VP8 codec turned out to be not so great, especially poor for still images. VP8 has lost to H.264, and meanwhile Cisco has found a loophole to sponsor H.264 royalties for all browsers. Other vendors have rejected WebP, partly because it was a non-standard Google's own thing (uncool move at a time when WHATWG was at its peak), but mainly because it just wasn't good enough, compared to optimized JPEG (Mozilla created MozJPEG to prove the point). Their bar for adoption is very high, since they're worried about maintaining things forever, bug-compatibility issues from a single implementation, increased code size, and attack surface. Mozilla and Safari have been resisting adoption of WebP for about 10 years. They've relented not because WebP got a "stable release" (total nonsense in the article), but because their bug trackers kept getting reports of Chrome-only websites and buggy HTTP content-negotiation that kept serving them "broken" images, to the point it started hurting their compatibility and costing them users. ---- With AVIF we've had the repeat of the video rush. Web has been once again been threatened by commercial H.265, with even messier and more expensive licensing, and no Cisco loophole this time. Browser vendors have banded around and adopted AV1 format ASAP to prevent dominance of H.265 on the Web. And just like WebP has been riding adoption of VP8, AVIF was riding on adoption of AV1. And once again, a video codec turned ot to be suboptimal for still images. Browsers didn't really care about adopting any image format. They cared about adoption of AV1 video, and AVIF got a pass only because it was almost for "free" (it's basically a 1-frame video file). (BTW, AV1 is based on VP10 + contributions from other vendors. This kinda makes it a descendant of WebP.) So from the perspective of browser vendors not really wanting any new image format, and getting one anyway, and AVIF being good enough to not need an urgent replacement, there's simply no appetite left for adopting yet another format. Browser vendors still don't like adding more code, and are still afraid of compatibility issues and attack surface. The conspiracies about money and power are hilarious.
hwbunny 2y ago
[flagged]
- TwentyPosts 2y ago
  Are you doing alright?
  - Citizen_Lame 2y ago
    [flagged]
- infotainment 2y ago
  ChatGPT has really revolutionized terrible poetry hasn’t it
  - hwbunny 2y ago
    At least it has some uses :D.
  - 6510 2y ago
    to make the bed they said, we got this in stead...
nextaccountic 2y ago
Why doesn't Firefox support JPEG XL?
- OuterVale 2y ago
  Mozilla has officially stated they are 'neutral' on the topic. I'd suggest this is due to influence from Google, which supports them financially, but I have very little hard evidence to back that up. They do have support in Firefox Nightly behind a flag, but it is disappointing they don't take a stronger stance. Firefox is really a shell of its former self due to Mozilla's handling of it in recent years, which is a real shame.
  - asadotzler 2y ago
    >but I have very little hard evidence to back that up. Bullshit. You have zero hard evidence to back that up.
ssttoo 2y ago
Here’s a “Give JXL a chance” song https://www.youtube.com/watch?v=VJaa1Le4W7c https://www.youtube.com/watch?v=VJaa1Le4W7c
unlord 2y ago
The article claims that "Google wants control, and JPEG XL could take that away from them" however this is disingenuous. The JPEG XL format was co-authored by Google employees, and they have just as much say over the direction of that format as they do WebP. The JPEG XL authors make claims about it's superiority over formats like AVIF, but there is no support or even timeline for hardware encode or decode on important platforms like mobile. By contrast, Qualcomm is adding support for AV1 encoding to Snapdragon X (https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-tablets/snapdragon-x-plus https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-...) which could lead to efficient encoding of AVIF photos and animations.
- janwas 2y ago
  > which could lead to efficient encoding of AVIF photos Efficient in what sense? HW encoders usually only explore a fraction of the search space, and in the case of JPEG often result in 3..5 bit per pixel images.
- OuterVale 2y ago
  Google most definitely had input in the creation of the format, but from all I can research, only at an early stage. As the project grew away from Pik they seem to have dropped interest and moved away from it. I have updated the article with more details about their involvement for transparency. If you have any information you can share with further information regarding Google's input, I'd open to hear it as evidence of their input as a company beyond preliminary stages has been difficult to find. --- Regarding JPEG XL's mobile support, it makes sense it would see limited development if the company that manages one of the biggest mobile players has been the greatest restriction on their success. The lack of support also disincentivises manufacturers to prioritise support.
  - unlord 2y ago
    > Regarding JPEG XL's mobile support, it makes sense it would see limited development if the company that manages one of the biggest mobile players has been the greatest restriction on their success. The lack of support also disincentivises manufacturers to prioritise support. There was literally no involvement from any hardware vendor in the standardization of JPEG XL. It went from a Call for Proposals in Sept 2018 to Committee Draft in Aug 2019 with very little time for industry feedback. Contrast this with AV1 which had involvement from hardware vendors Intel, NVIDIA, Arm, AMD, Broadcom, Amlogic from the beginning as well as companies who ship media on hardware at scale such as Cisco, Netflix, Samsung and yes Google. These companies reviewed and provided significant feedback on the format that made it suitable for hardware implementation. https://news.ycombinator.com/threads?id=JyrkiAlakuijala https://news.ycombinator.com/threads?id=JyrkiAlakuijala is a lead on the project and a Google employee, and active in JPEG XL development https://github.com/libjxl/libjxl/commits?author=jyrkialakuijala https://github.com/libjxl/libjxl/commits?author=jyrkialakuij...
orangesite 2y ago
This article should be forwarded to the US gov antitrust division. I suspect it would be of great interest given their current activities.

77 points by OuterVale 2y ago

It's superficial analysis to assume that when Mozilla agrees with Google, it's about money. That's merely correlation. Other people and organizations can disagree with your arguments in ways that you don't think are logical or sound, but that doesn't mean they aren't just based on different weights and criteria. It's not useful to assume the decision criteria, because it becomes too easy to declare yourself right yet be confused why other people don't recognize it. Never simply attribute to malice what can be explained by incompetence, but also never simply attribute to incompetence what can be explained by disagreement.

barfbagginus 2y ago
The argument is that pressuring Mozilla is a valid second line of attack, on top of pressuring Google. That seems fairly benign, given that Google and Mozilla both have power in the browser ecosystem. I don't see any assumptions about Mozilla's motive, or think it would be relevant to assume motive one way or another. The assumption is that Mozilla has power to help fuel JPEG XL adoption, so that pressure wouldn't simply be wasted. Now, I'm not sure it has this power given its 3% browser market share. This might invalidate the particular argument. That said, there are many valid reasons to give Mozilla execs grief, and many valid reasons to work to deconstruct Mozilla's leadership. So I don't mind if people do it over JPEG-XL, even if Mozilla's had zero power to affect JPEG-XL.
- kodabbb 2y ago
  this is so toxic it's not even funny
  - barfbagginus 2y ago
    It's perfectly fine to be toxic and unfunny towards Mozilla's C-suite, kodabbb

pornel 2y ago

The article has a warped timeline of WebP, with incorrect speculation, and missing key points. WebP has been created in the rush of wild optimism after Google has freed the VP8 video format (WebM). VP8 has been strategically important for them (and YouTube), because before then Web video has been at mercy of Flash, Silverlight, and threatened by H.264 patent royalties. The WebP format has been rushed. It didn't go through a usual standards process. The VP8 codec turned out to be not so great, especially poor for still images. VP8 has lost to H.264, and meanwhile Cisco has found a loophole to sponsor H.264 royalties for all browsers. Other vendors have rejected WebP, partly because it was a non-standard Google's own thing (uncool move at a time when WHATWG was at its peak), but mainly because it just wasn't good enough, compared to optimized JPEG (Mozilla created MozJPEG to prove the point). Their bar for adoption is very high, since they're worried about maintaining things forever, bug-compatibility issues from a single implementation, increased code size, and attack surface. Mozilla and Safari have been resisting adoption of WebP for about 10 years. They've relented not because WebP got a "stable release" (total nonsense in the article), but because their bug trackers kept getting reports of Chrome-only websites and buggy HTTP content-negotiation that kept serving them "broken" images, to the point it started hurting their compatibility and costing them users. ---- With AVIF we've had the repeat of the video rush. Web has been once again been threatened by commercial H.265, with even messier and more expensive licensing, and no Cisco loophole this time. Browser vendors have banded around and adopted AV1 format ASAP to prevent dominance of H.265 on the Web. And just like WebP has been riding adoption of VP8, AVIF was riding on adoption of AV1. And once again, a video codec turned ot to be suboptimal for still images. Browsers didn't really care about adopting any image format. They cared about adoption of AV1 video, and AVIF got a pass only because it was almost for "free" (it's basically a 1-frame video file). (BTW, AV1 is based on VP10 + contributions from other vendors. This kinda makes it a descendant of WebP.) So from the perspective of browser vendors not really wanting any new image format, and getting one anyway, and AVIF being good enough to not need an urgent replacement, there's simply no appetite left for adopting yet another format. Browser vendors still don't like adding more code, and are still afraid of compatibility issues and attack surface. The conspiracies about money and power are hilarious.

hwbunny 2y ago

[flagged]

TwentyPosts 2y ago
Are you doing alright?
- Citizen_Lame 2y ago
  [flagged]
infotainment 2y ago
ChatGPT has really revolutionized terrible poetry hasn’t it
- hwbunny 2y ago
  At least it has some uses :D.
- 6510 2y ago
  to make the bed they said, we got this in stead...

nextaccountic 2y ago

Why doesn't Firefox support JPEG XL?

OuterVale 2y ago
Mozilla has officially stated they are 'neutral' on the topic. I'd suggest this is due to influence from Google, which supports them financially, but I have very little hard evidence to back that up. They do have support in Firefox Nightly behind a flag, but it is disappointing they don't take a stronger stance. Firefox is really a shell of its former self due to Mozilla's handling of it in recent years, which is a real shame.
- asadotzler 2y ago
  >but I have very little hard evidence to back that up. Bullshit. You have zero hard evidence to back that up.

ssttoo 2y ago

Here’s a “Give JXL a chance” song https://www.youtube.com/watch?v=VJaa1Le4W7c https://www.youtube.com/watch?v=VJaa1Le4W7c

unlord 2y ago

The article claims that "Google wants control, and JPEG XL could take that away from them" however this is disingenuous. The JPEG XL format was co-authored by Google employees, and they have just as much say over the direction of that format as they do WebP. The JPEG XL authors make claims about it's superiority over formats like AVIF, but there is no support or even timeline for hardware encode or decode on important platforms like mobile. By contrast, Qualcomm is adding support for AV1 encoding to Snapdragon X (https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-tablets/snapdragon-x-plus https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-...) which could lead to efficient encoding of AVIF photos and animations.

janwas 2y ago
> which could lead to efficient encoding of AVIF photos Efficient in what sense? HW encoders usually only explore a fraction of the search space, and in the case of JPEG often result in 3..5 bit per pixel images.
OuterVale 2y ago
Google most definitely had input in the creation of the format, but from all I can research, only at an early stage. As the project grew away from Pik they seem to have dropped interest and moved away from it. I have updated the article with more details about their involvement for transparency. If you have any information you can share with further information regarding Google's input, I'd open to hear it as evidence of their input as a company beyond preliminary stages has been difficult to find. --- Regarding JPEG XL's mobile support, it makes sense it would see limited development if the company that manages one of the biggest mobile players has been the greatest restriction on their success. The lack of support also disincentivises manufacturers to prioritise support.
- unlord 2y ago
  > Regarding JPEG XL's mobile support, it makes sense it would see limited development if the company that manages one of the biggest mobile players has been the greatest restriction on their success. The lack of support also disincentivises manufacturers to prioritise support. There was literally no involvement from any hardware vendor in the standardization of JPEG XL. It went from a Call for Proposals in Sept 2018 to Committee Draft in Aug 2019 with very little time for industry feedback. Contrast this with AV1 which had involvement from hardware vendors Intel, NVIDIA, Arm, AMD, Broadcom, Amlogic from the beginning as well as companies who ship media on hardware at scale such as Cisco, Netflix, Samsung and yes Google. These companies reviewed and provided significant feedback on the format that made it suitable for hardware implementation. https://news.ycombinator.com/threads?id=JyrkiAlakuijala https://news.ycombinator.com/threads?id=JyrkiAlakuijala is a lead on the project and a Google employee, and active in JPEG XL development https://github.com/libjxl/libjxl/commits?author=jyrkialakuijala https://github.com/libjxl/libjxl/commits?author=jyrkialakuij...

orangesite 2y ago

This article should be forwarded to the US gov antitrust division. I suspect it would be of great interest given their current activities.