4 ms·

What I don’t understand is, why still push for JPEG XL when webP already has a lot of support and AVIF has a lot of momentum?

by jorvi 3y ago

pgeorgi 3y ago
According to the article, WebP requires more CPU to decode. JPEG XL also supports lossless transcoding from JPEG, so it could be used for old image sets with no loss in image fidelity. There are arguments for the new format, but the Chrome people seemed unwilling to maintain support for it when pick-up was non-existent (Firefox could have moved it out of their purgatory. Safari could have implemented it earlier. Edge could have enabled it by default. Sites could use polyfills to demonstrate that they want the desirable properties. And so on.) To me, the situation was one of "If Chrome enables it, people will whine how Chrome forces file formats onto everybody, making the web platform harder to reimplement, a clear signal of domination. If they don't enable it, people will whine how Chrome doesn't push the format, a clear signal of domination", and they chose to use the variant of the lose-lose scenario that means less work down the road.
- cubefox 3y ago
  > There are arguments for the new format, but the Chrome people seemed unwilling to maintain support for it when pick-up was non-existent Of course there is no pick-up when Chrome, with its massive market share, doesn't support it. Demanding pick-up before support makes no sense for an entity with such a large dominance.
  - pgeorgi 3y ago
    - Polyfills (there _is_ polyfill-enabling code - maintained by Chrome devs.) - Microsoft enabling the flag in Edge by default and telling people that websites can be 30% smaller/faster in Edge, automatically adding JXL conversion in their web frameworks - Apple doing the same with Safari (what they're _now_ doing) - Mozilla doing the same with Firefox (instead of hiding that feature in a developer-only build behind a flag) None of that happened so far, only the mixed signal of "lead and we'll follow" and "you are too powerful, stop dominating us." in some issue tracker _after_ the code has been removed.
    - cubefox 3y ago
      Why are you talking about Microsoft, Apple, and Mozilla, when Chrome has a larger market share than all of them? > "you are too powerful, stop dominating us." That's twisting things. The problem was that the argument of the Chrome team against JPEG XL was self-refuting. They were themselves the main cause of what they complained about.
      - pgeorgi 3y ago
        Because Microsoft, Apple and Mozilla can still exert pressure: "Support this feature we enabled and benefit from 20% less traffic with users of our browsers" and "Use Edge/Safari/Firefox to browse the web faster (and with metered connections: cheaper)" still has an effect on Chrome's decision making. Chrome had that code, hidden behind a flag. There wasn't any kind of activity. No questions "when will you put it in by default in Chrome?". No other Blink-based browser (Edge, Brave, Vivaldi, Opera) that could easily pick up the support by enabling that damn flag by default did so. Firefox hid JXL support even better than Chrome. No image sharing site that did the math and considered "200KB for a polyfill saves us and our users megabytes in traffic on each visit" and acted on that. That doesn't look like anybody is interested in JXL support. I'm bringing this up again and again because I dislike that notion of "Chrome is the market leader and we're powerless to do anything about it. Bad Google." It neither encourages the Chrome folks to do better nor anybody else to pick up the slack. It's 100% complaint, no matter what Chrome does.
  - fireweed 3y ago
    That's why I hate Chrome's monopoly.
CuriousCosmic 3y ago
JPEG XL and AVIF have tradeoffs. AVIF works extremely well at compressing images down to very small sizes with minimal losses in quality but loses comparatively to JPEG XL when it comes to compression at higher quality. Also I believe AVIF has an upper limit on canvas sizes (2^16 pixels by 2^16 pixels I think) where JEPGXL doesn't have that limitation. Also existing JPEGs can be losslessly migrated to JPEGXL which is preferable to a lossy conversion to AVIF. So it's preferable to have JPEG XL, webP, and AVIF. - webP fills the PNG role while providing better lossless compression - AVIF fills the JPEG role for most of your standard web content. - JPEG XL migrates old JPEG content to get most of the benefits of JPEG XL or AVIF without lossy conversion. - JPEG XL fills your very-high fidelity image role (currently filled by very large JPEGs or uncompressed TIFFs) while providing very good lossless and lossy compression options.
- wongarsu 3y ago
  AVIF is even more limited in resolution than that, just 8.9 megapixels in baseline profile or 35 megapixels in the advanced profile. If you have image-heavy workflows and care about storage and/or bandwidth then JPEG-XL pairs great with AVIF: JPEG-XL is great for originals and detail views due to its great performance at high quality settings and high resolution support, meanwhile AVIF excels at thumbnails where resolution doesn't matter and you need good performance at low quality settings.
- prox 3y ago
  Memory is hazy but doesn’t JXL have better colors or color profile support?
  - vanderZwan 3y ago
    You can scroll down (on mobile) to see an overview image comparing technical features on https://jpegxl.info/ https://jpegxl.info/. It doesn't mention color profiles (although I presume that just means they're all equal there), but jxl does support higher max bit depth per channel (32 vs 10 for AVIF) and more channels (4099 vs 10). So for raw sensor data, and intermediate formats for image processing, where information loss should be avoided, it should be a lot better. I'm hoping it gets adopted as a better underlying technology for various RAW formats, and hopefully a better successor to the DNG format while we're at it (currently these are TIFF based). I'm not even a professional photographer, and my hard drive is still mostly occupied by RAW files.

What I don’t understand is, why still push for JPEG XL when webP already has a lot of support and AVIF has a lot of momentum?

by jorvi 3y ago

What I don’t understand is, why still push for JPEG XL when webP already has a lot of support and AVIF has a lot of momentum?

pgeorgi 3y ago

According to the article, WebP requires more CPU to decode. JPEG XL also supports lossless transcoding from JPEG, so it could be used for old image sets with no loss in image fidelity. There are arguments for the new format, but the Chrome people seemed unwilling to maintain support for it when pick-up was non-existent (Firefox could have moved it out of their purgatory. Safari could have implemented it earlier. Edge could have enabled it by default. Sites could use polyfills to demonstrate that they want the desirable properties. And so on.) To me, the situation was one of "If Chrome enables it, people will whine how Chrome forces file formats onto everybody, making the web platform harder to reimplement, a clear signal of domination. If they don't enable it, people will whine how Chrome doesn't push the format, a clear signal of domination", and they chose to use the variant of the lose-lose scenario that means less work down the road.

cubefox 3y ago
> There are arguments for the new format, but the Chrome people seemed unwilling to maintain support for it when pick-up was non-existent Of course there is no pick-up when Chrome, with its massive market share, doesn't support it. Demanding pick-up before support makes no sense for an entity with such a large dominance.
- pgeorgi 3y ago
  - Polyfills (there _is_ polyfill-enabling code - maintained by Chrome devs.) - Microsoft enabling the flag in Edge by default and telling people that websites can be 30% smaller/faster in Edge, automatically adding JXL conversion in their web frameworks - Apple doing the same with Safari (what they're _now_ doing) - Mozilla doing the same with Firefox (instead of hiding that feature in a developer-only build behind a flag) None of that happened so far, only the mixed signal of "lead and we'll follow" and "you are too powerful, stop dominating us." in some issue tracker _after_ the code has been removed.
  - cubefox 3y ago
    Why are you talking about Microsoft, Apple, and Mozilla, when Chrome has a larger market share than all of them? > "you are too powerful, stop dominating us." That's twisting things. The problem was that the argument of the Chrome team against JPEG XL was self-refuting. They were themselves the main cause of what they complained about.
    - pgeorgi 3y ago
      Because Microsoft, Apple and Mozilla can still exert pressure: "Support this feature we enabled and benefit from 20% less traffic with users of our browsers" and "Use Edge/Safari/Firefox to browse the web faster (and with metered connections: cheaper)" still has an effect on Chrome's decision making. Chrome had that code, hidden behind a flag. There wasn't any kind of activity. No questions "when will you put it in by default in Chrome?". No other Blink-based browser (Edge, Brave, Vivaldi, Opera) that could easily pick up the support by enabling that damn flag by default did so. Firefox hid JXL support even better than Chrome. No image sharing site that did the math and considered "200KB for a polyfill saves us and our users megabytes in traffic on each visit" and acted on that. That doesn't look like anybody is interested in JXL support. I'm bringing this up again and again because I dislike that notion of "Chrome is the market leader and we're powerless to do anything about it. Bad Google." It neither encourages the Chrome folks to do better nor anybody else to pick up the slack. It's 100% complaint, no matter what Chrome does.
- fireweed 3y ago
  That's why I hate Chrome's monopoly.

CuriousCosmic 3y ago

JPEG XL and AVIF have tradeoffs. AVIF works extremely well at compressing images down to very small sizes with minimal losses in quality but loses comparatively to JPEG XL when it comes to compression at higher quality. Also I believe AVIF has an upper limit on canvas sizes (2^16 pixels by 2^16 pixels I think) where JEPGXL doesn't have that limitation. Also existing JPEGs can be losslessly migrated to JPEGXL which is preferable to a lossy conversion to AVIF. So it's preferable to have JPEG XL, webP, and AVIF. - webP fills the PNG role while providing better lossless compression - AVIF fills the JPEG role for most of your standard web content. - JPEG XL migrates old JPEG content to get most of the benefits of JPEG XL or AVIF without lossy conversion. - JPEG XL fills your very-high fidelity image role (currently filled by very large JPEGs or uncompressed TIFFs) while providing very good lossless and lossy compression options.

wongarsu 3y ago
AVIF is even more limited in resolution than that, just 8.9 megapixels in baseline profile or 35 megapixels in the advanced profile. If you have image-heavy workflows and care about storage and/or bandwidth then JPEG-XL pairs great with AVIF: JPEG-XL is great for originals and detail views due to its great performance at high quality settings and high resolution support, meanwhile AVIF excels at thumbnails where resolution doesn't matter and you need good performance at low quality settings.
prox 3y ago
Memory is hazy but doesn’t JXL have better colors or color profile support?
- vanderZwan 3y ago
  You can scroll down (on mobile) to see an overview image comparing technical features on https://jpegxl.info/ https://jpegxl.info/. It doesn't mention color profiles (although I presume that just means they're all equal there), but jxl does support higher max bit depth per channel (32 vs 10 for AVIF) and more channels (4099 vs 10). So for raw sensor data, and intermediate formats for image processing, where information loss should be avoided, it should be a lot better. I'm hoping it gets adopted as a better underlying technology for various RAW formats, and hopefully a better successor to the DNG format while we're at it (currently these are TIFF based). I'm not even a professional photographer, and my hard drive is still mostly occupied by RAW files.