4 ms·

Thanks, that all sounds fairly reasonable then.

• gsich 4y ago
  Not really. It was hidden behind a flag, so where should the "entire ecosystem" (who?) show interest?
  • vonbon 4y ago
    Couldn't any interested parties just enable the flag for testing? That doesn't seem a insurmountable challenge, given that the code is, or was, already in there.
    • hmry 4y ago
      Well, I am interested in saving server bandwidth by delivering smaller image files at the same quality. I can't enable a flag on my user's browsers though. :)
  • sk65535 4y ago
    you know, industry / browser people talk to each other. But not necessary on social media. Or publicly.
    • croes 4y ago
      Yep, and they wanted support for JPEG XL
  • phillipseamore 4y ago
    The ecosystem are the other browser vendors.
    • usefulcat 4y ago
      ..who together compose what, like 10% of the browser market?
      • phillipseamore 4y ago
        At 100% depending on the platform. For years many have complained about Chrome moving too fast and shipping stuff without a consensus with the other vendors, this might signal a change from that.
        • Dylan16807 4y ago
          Waiting for consensus from other browsers while ignoring consensus from the broader software industry is not what most people meant.
    • iggldiggl 4y ago
      By that logic WebP should have never got out of the door, because all non-Chromium browsers were explicitly reticent in implementing support for it and only finally started doing so with several years delay (in the case of Apple several years even more). But of course WebP was Google's own image format…
      • phillipseamore 4y ago
        It took the other browsers up to a decade to support WebP, who wants to do that again? JPEG-XL is based on the Google Pik proposal among other things and they were active in the spec'ing - there is no conspiracy here.
        • iggldiggl 4y ago
          Yes, fair enough, parts of Google contributed to JPEG-XL, too. But the basic gist remains – for WebP they decided it was the greatest thing since slice bread and enabled it regardless of what the rest of the "ecosystem" thought, whereas now all of a sudden they're supposedly that much concerned, even though Chrome is by far and large the majority of that ecosystem, Apple prefers their own format choices anyway, and it's not as if it's not also a chicken-and-egg situation.
          • brigade 4y ago
            Yes, they recognize now that WebP was a mistake, which is why they won’t single-handedly force any more image formats upon the web. (Safari learned this lesson earlier when they got stuck being the only browser to support JPEG2000, and Microsoft with JPEG-XR)
            • jonsneyers 4y ago
              Have you heard about AVIF?
          • phillipseamore 4y ago
            Things can change in 12 years. Google also killed off it's WEBP v2 development last month. Apple is all in on AVIF/AV1 but has shown little to no interest in JXL (might be burnt from back when they supported JP2).
    • brigade 4y ago
      Also cameras. Which either aren’t interested (no one really cares about non-RAW formats on DSLRs), or are going AVIF once hardware encoders land (Android phones)
      • quikee 4y ago
        DSLR market has pretty much stopped (rarely any new DSLR camera is released) as everyone shifted to mirrorless cameras. Camera manufacturers mostly added HEIF (Canon, Sony, Fuji) as the non-RAW image format, because they already have HEVC for video. Camera with a lossy / lossless 12-bit, 14-bit JPEG XL would definitely be interesting for many photographers. Not everyone wants to be forced to do a complete post-processing with RAW. JPEG is to limited (8-bit only) and HEIF isn't much better, while not having much support (especially on the web) because of the patent situation.
        • JyrkiAlakuijala 4y ago
          Fully agree with this sentiment. Also good to know that Jpegli (a traditional jpeg codec within libjxl) allows for 16 bit input and output for '8-bit jpegs' and can deliver about ~12 bits of dynamics for the slowest gradients and ~10.5 bits for the usual photographs. Jpegli improves existing jpeg images by about 8 % by doing decoding more precisely. Jpegli allows for encoding jpeg images 30 % more efficiently by using JPEG XL adaptive quantization (by borrowing guetzli's variable dead zone trick), and the XYB colorspace from JPEG XL. Together, you get about 35 % savings by using jpegli from the decoding + encoding improvements. Also, you get traditional JPEG that works with HDR. Jpegli is predicted to be production ready in April or so, but can be benchmarked already.
      • JyrkiAlakuijala 4y ago
        jpeg xl can power raw formats and raw-like lossless formats, and is super interesting in that domain another format that is limited to three channels or has bit depth limitations would not be similarly interesting another format that is for example 50 % worse in lossless compression would not be interesting in this space
    • gsich 4y ago
      Firefox has it on Nightly. Not great either.