4 ms·

Strange that Mozilla is going to rely on an internal team at Google to build a decoder for them in Rust, when Google is the one trying to kill JPEGXL.

Mindless2112 1y ago
It's two different teams inside Google. Some part of the Chrome team is trying to quash JPEG XL.
- righthand 1y ago
  Sure, but if it becomes political I expect the Chrome team to fully quash the JPEG XL team to hurt Firefox and JPEG XL in one go.
  - breppp 1y ago
    It's more likely related to security, image formats are a huge attack surface for browsers and they are hard to remove once added. JPEG XL was written in C++ in a completely different part of Google without any of the safe vanity wuffs style code, and the Chrome team probably had its share of trouble with half baked compression formats (webp)
  - lonjil 1y ago
    Other than Jon at Cloudinary, everyone involved with JXL development, from creation of the standard to the libjxl library, works at Google Research in Zurich. The Chrome team in California has zero authority over them. They've also made a lot of stuff that's in Chrome, like Lossless WebP, Brotli, WOFF, the Highway SIMD library (actually created for libjxl and later spun off).
  - refulgentis 1y ago
    I'd argue the thread up through the comment you are replying to is fact-free gossiping - I'm wondering if it was an invitation to repeat the fact-free gossip, the comment doesn't read that way. Reads to me as more exasperated, so exasperated they're willing to speak publicly and establish facts. My $0.02, since the gap here on perception of the situation fascinates me: JPEG XL as a technical project was a real nightmare, I am not surprised at all to find Mozilla is waiting for a real decoder. If you get _any_ FAANG engineer involved in this mess a beer || truth serum, they'll have 0 idea why this has so much mindshare, modulo it sounds like something familiar (JPEG) and people invented nonsense like "Chrome want[s] to kill it" while it has the attention of an absurd amount of engineers to get it into shipping shape. (surprisingly, Firefox is not attributed this - they also do not support it yet, and they are not doing anything _other_ than awaiting Chrome's work for it!)
    - Implicated 1y ago
      > they'll have 0 idea why this has so much mindshare Considering the amount of storage all of these companies are likely allocating to storing jpegs + the bandwidth of it all - maybe the instant file size wins?
      - bawolff 1y ago
        Hard disk and bandwidth of jpegs are almost certainly negligible in the era of streaming video. The biggest selling point is probably client side latency from downloading the file. We barely even have movement to webp &avif, if this was a critical issue i would expect a lot more movement on that front since it already exists. From what i understand avif gives better compression (except for lossless) and has better decoding speed than jxl anyways.
        danielheath 1y ago
        jxl let’s you further compress existing JPEG files without additional artifacting, which is significant given how many jpeg files already exist.
        lonjil 1y ago
        > We barely even have movement to webp &avif If you look at CDNs, WebP and AVIF are very popular. > From what i understand avif gives better compression (except for lossless) and has better decoding speed than jxl anyways. AVIF is better at low to medium quality, and JXL is better at medium to high quality. JXL decoding speed is pretty much constant regardless of how you vary the quality parameter, but AVIF gets faster and faster to decode as you reduce the quality; it's only faster to decode than JXL for low quality images. And about half of all JPEG images on the web are high quality. The Chrome team really dislikes the concept of high quality images on the web for some reason though, that's why they only push formats that are optimized for low quality. WebP beats JPEG at low quality, but is literally incapable of very high quality[1] and is worse than JPEG at high quality. AVIF is really good at low quality but fails to be much of an improvement at high quality. For high resolution in combination with high quality, AVIF even manages to be worse than JPEG. [1] Except for the lossless mode which was developed by Jyrki at Google Zurich in response to Mozilla's demand that any new web image format should have good lossless support.
spider-mario 1y ago
Those writing the new Rust decoder are largely people who worked on the standard and on the original C++ implementation, + contributions from the author of jxl-oxide (who is not at Google).
bawolff 1y ago
Sheesh. Google isn't trying to kill jxl, they just think its a bad fit for their product. There is a huge difference between deciding not to do something because the benefit vs complexity trade off doesn't make sense, and actively trying to kill something. FWIW i agree with google, avif is a much better format for the web. Pathology imaging is a bit of a different use case, where jpeg-xl is a better fit than avif would be.
- deleted 1y ago
  [deleted]

Mindless2112 1y ago

It's two different teams inside Google. Some part of the Chrome team is trying to quash JPEG XL.

righthand 1y ago
Sure, but if it becomes political I expect the Chrome team to fully quash the JPEG XL team to hurt Firefox and JPEG XL in one go.
- breppp 1y ago
  It's more likely related to security, image formats are a huge attack surface for browsers and they are hard to remove once added. JPEG XL was written in C++ in a completely different part of Google without any of the safe vanity wuffs style code, and the Chrome team probably had its share of trouble with half baked compression formats (webp)
- lonjil 1y ago
  Other than Jon at Cloudinary, everyone involved with JXL development, from creation of the standard to the libjxl library, works at Google Research in Zurich. The Chrome team in California has zero authority over them. They've also made a lot of stuff that's in Chrome, like Lossless WebP, Brotli, WOFF, the Highway SIMD library (actually created for libjxl and later spun off).
- refulgentis 1y ago
  I'd argue the thread up through the comment you are replying to is fact-free gossiping - I'm wondering if it was an invitation to repeat the fact-free gossip, the comment doesn't read that way. Reads to me as more exasperated, so exasperated they're willing to speak publicly and establish facts. My $0.02, since the gap here on perception of the situation fascinates me: JPEG XL as a technical project was a real nightmare, I am not surprised at all to find Mozilla is waiting for a real decoder. If you get _any_ FAANG engineer involved in this mess a beer || truth serum, they'll have 0 idea why this has so much mindshare, modulo it sounds like something familiar (JPEG) and people invented nonsense like "Chrome want[s] to kill it" while it has the attention of an absurd amount of engineers to get it into shipping shape. (surprisingly, Firefox is not attributed this - they also do not support it yet, and they are not doing anything _other_ than awaiting Chrome's work for it!)
  - Implicated 1y ago
    > they'll have 0 idea why this has so much mindshare Considering the amount of storage all of these companies are likely allocating to storing jpegs + the bandwidth of it all - maybe the instant file size wins?
    - bawolff 1y ago
      Hard disk and bandwidth of jpegs are almost certainly negligible in the era of streaming video. The biggest selling point is probably client side latency from downloading the file. We barely even have movement to webp &avif, if this was a critical issue i would expect a lot more movement on that front since it already exists. From what i understand avif gives better compression (except for lossless) and has better decoding speed than jxl anyways.
      - danielheath 1y ago
        jxl let’s you further compress existing JPEG files without additional artifacting, which is significant given how many jpeg files already exist.
      - lonjil 1y ago
        > We barely even have movement to webp &avif If you look at CDNs, WebP and AVIF are very popular. > From what i understand avif gives better compression (except for lossless) and has better decoding speed than jxl anyways. AVIF is better at low to medium quality, and JXL is better at medium to high quality. JXL decoding speed is pretty much constant regardless of how you vary the quality parameter, but AVIF gets faster and faster to decode as you reduce the quality; it's only faster to decode than JXL for low quality images. And about half of all JPEG images on the web are high quality. The Chrome team really dislikes the concept of high quality images on the web for some reason though, that's why they only push formats that are optimized for low quality. WebP beats JPEG at low quality, but is literally incapable of very high quality[1] and is worse than JPEG at high quality. AVIF is really good at low quality but fails to be much of an improvement at high quality. For high resolution in combination with high quality, AVIF even manages to be worse than JPEG. [1] Except for the lossless mode which was developed by Jyrki at Google Zurich in response to Mozilla's demand that any new web image format should have good lossless support.

spider-mario 1y ago

Those writing the new Rust decoder are largely people who worked on the standard and on the original C++ implementation, + contributions from the author of jxl-oxide (who is not at Google).

bawolff 1y ago

Sheesh. Google isn't trying to kill jxl, they just think its a bad fit for their product. There is a huge difference between deciding not to do something because the benefit vs complexity trade off doesn't make sense, and actively trying to kill something. FWIW i agree with google, avif is a much better format for the web. Pathology imaging is a bit of a different use case, where jpeg-xl is a better fit than avif would be.

deleted 1y ago
[deleted]