3 ms·

Was there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it? I barely heard about it at all. Perhaps

by gman83 4y ago

Was there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it? I barely heard about it at all. Perhaps if Google wants to create developer enthusiasm for some new feature they want to implement, they should first announce they're NOT going to be implementing said feature, then when the inevitable backlash happens, very publicly backtrack.

dmitriid 4y ago
Google don't need to resort to such tricks when they can just bludgeon everyone to death. Se how they forced support of VP9 and AV1: https://www.protocol.com/youtube-tv-roku-issues https://www.protocol.com/youtube-tv-roku-issues
- rob74 4y ago
  Not to mention WebP, which I guess is the elephant in the room when they say that JPEG XL "does not bring sufficient incremental benefits over existing formats".
  - gruturo 4y ago
    And which is very unconvincing in real world use.... It benchmarks well, but "looks" crap. I really wish they had produced something better than that, if that's what we're going to be stuck with. It's sad.
    - JyrkiAlakuijala 4y ago
      JPEG XL is the other way around: Okeyish/boring in usual PSNR, SSIM, VMAF benchmarks, great in benchmarks with DSSIM, SSIMULACRA2 and Butteraugli, but looks superb to humans.
      - gruturo 4y ago
        And it addresses a very, very real use case of recompressing JPEGs without generation loss. Considering that a vast majority of all pictures being taken even today begin their life as JPEGs, that's very relevant.
  - chungy 4y ago
    I mean, WebP is _okay_ but it leaves a lot to be desired, even when it comes to image quality compared to the old 1992 JPEG standard; coupled with mozjpeg making giant leaps to get old-school JPEG file sizes drastically smaller without costing quality, the original file size advantage WebP pitched is not as large of a selling point. WebP's best quality is that in lossless mode, it usually results in smaller files than PNGs, but given that it was primarily focused at being a lossy format to replace JPEG, with a 16383×16383 size limit[1], color space fixed at YUV 4:2:0 only[2], marginal space savings, no progressive decoding, it comes up short in a number of scenarios. There's also the breadth of legacy JPEG-encoded files without a good transition story to WebP, especially due to most JPEGs in the world not being of YUV 4:2:0 format. I sound like I'm hating WebP here and I'm not trying to, but my own personal uses for WebP have been squarely in the lossless mode side with a JPEG-encoded thumbnail to accompany it. WebP's primary selling point were file size benefits, but then mozjpeg really not just improved JPEG 1992, but made it a compelling choice to use instead of WebP. JPEG XL really stands to be the best of everything. No fixed colorspace model, no image size limits, smaller lossy and lossless files than previous formats, progressive decoding, etc. It's a solid win for JPEG XL, especially if browsers start adopting it for production. [1] Size limit applies to lossy and lossless mode both. [2] Lossless mode's color space is fixed at 32-bit BGRA only. Same issue, different spec.
  - KingMob 4y ago
    I don't personally know if that's true for JPEG XL, but WebP was kind of underwhelming. I remember all the same conversations happening now on HN, but for WebP back in the day, and Mozilla being really doubtful it was worth the maintenance effort. FF eventually added it... in 2019, and Safari in 2020. Only two years later we're discussing a format that will completely supplant it, but the browsers will have to maintain WebP forever.
  - account42 4y ago
    Also brotli - not that its a bad format but its weird how quickly it made it into browsers without proving itself first when there have been so many general purpose compression algorithms better than gzip that were just ignored.
    - JyrkiAlakuijala 4y ago
      Brotli got into browsers quickly because W3C Web Fonts Working Group knew how to collaborate (instead of have the usual infinite quarrels :-D). I am thankful to Vladimir Levantovsky for somehow having created this atmosphere -- and of course to all the working group members. Previously some engineers tried to bring bzip2 into content encoding, that failed by HTTP/tv-top-boxes interacting. HTTPS getting more common allowed a safer deployment route. The W3C WG was trying to bring LZMA in, but that was just too slow for all fonts decoding -- it would have not made fonts load faster in all cases.
lonjil 4y ago
> Was there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it? Not sure if it counts as momentum, but engineers representing Facebook, Intel/VESA, Shopify, Adobe, and more have been asking for JXL to be enabled in Chrome without a flag for quite a while now.

by gman83 4y ago

dmitriid 4y ago

Google don't need to resort to such tricks when they can just bludgeon everyone to death. Se how they forced support of VP9 and AV1: https://www.protocol.com/youtube-tv-roku-issues https://www.protocol.com/youtube-tv-roku-issues

rob74 4y ago
Not to mention WebP, which I guess is the elephant in the room when they say that JPEG XL "does not bring sufficient incremental benefits over existing formats".
- gruturo 4y ago
  And which is very unconvincing in real world use.... It benchmarks well, but "looks" crap. I really wish they had produced something better than that, if that's what we're going to be stuck with. It's sad.
  - JyrkiAlakuijala 4y ago
    JPEG XL is the other way around: Okeyish/boring in usual PSNR, SSIM, VMAF benchmarks, great in benchmarks with DSSIM, SSIMULACRA2 and Butteraugli, but looks superb to humans.
    - gruturo 4y ago
      And it addresses a very, very real use case of recompressing JPEGs without generation loss. Considering that a vast majority of all pictures being taken even today begin their life as JPEGs, that's very relevant.
- chungy 4y ago
  I mean, WebP is _okay_ but it leaves a lot to be desired, even when it comes to image quality compared to the old 1992 JPEG standard; coupled with mozjpeg making giant leaps to get old-school JPEG file sizes drastically smaller without costing quality, the original file size advantage WebP pitched is not as large of a selling point. WebP's best quality is that in lossless mode, it usually results in smaller files than PNGs, but given that it was primarily focused at being a lossy format to replace JPEG, with a 16383×16383 size limit[1], color space fixed at YUV 4:2:0 only[2], marginal space savings, no progressive decoding, it comes up short in a number of scenarios. There's also the breadth of legacy JPEG-encoded files without a good transition story to WebP, especially due to most JPEGs in the world not being of YUV 4:2:0 format. I sound like I'm hating WebP here and I'm not trying to, but my own personal uses for WebP have been squarely in the lossless mode side with a JPEG-encoded thumbnail to accompany it. WebP's primary selling point were file size benefits, but then mozjpeg really not just improved JPEG 1992, but made it a compelling choice to use instead of WebP. JPEG XL really stands to be the best of everything. No fixed colorspace model, no image size limits, smaller lossy and lossless files than previous formats, progressive decoding, etc. It's a solid win for JPEG XL, especially if browsers start adopting it for production. [1] Size limit applies to lossy and lossless mode both. [2] Lossless mode's color space is fixed at 32-bit BGRA only. Same issue, different spec.
- KingMob 4y ago
  I don't personally know if that's true for JPEG XL, but WebP was kind of underwhelming. I remember all the same conversations happening now on HN, but for WebP back in the day, and Mozilla being really doubtful it was worth the maintenance effort. FF eventually added it... in 2019, and Safari in 2020. Only two years later we're discussing a format that will completely supplant it, but the browsers will have to maintain WebP forever.
- account42 4y ago
  Also brotli - not that its a bad format but its weird how quickly it made it into browsers without proving itself first when there have been so many general purpose compression algorithms better than gzip that were just ignored.
  - JyrkiAlakuijala 4y ago
    Brotli got into browsers quickly because W3C Web Fonts Working Group knew how to collaborate (instead of have the usual infinite quarrels :-D). I am thankful to Vladimir Levantovsky for somehow having created this atmosphere -- and of course to all the working group members. Previously some engineers tried to bring bzip2 into content encoding, that failed by HTTP/tv-top-boxes interacting. HTTPS getting more common allowed a safer deployment route. The W3C WG was trying to bring LZMA in, but that was just too slow for all fonts decoding -- it would have not made fonts load faster in all cases.

lonjil 4y ago

> Was there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it? Not sure if it counts as momentum, but engineers representing Facebook, Intel/VESA, Shopify, Adobe, and more have been asking for JXL to be enabled in Chrome without a flag for quite a while now.