12 ms·

Sad day for image formats. JXL really looked like the future, it could have replaced all the image formats I use on my websites. Especially the lossless JPEG re

• iLoveOncall 4y ago
  JPEG XL was not used anywhere which is why it got deprecated. It was never gonna be the future of anything.
  • ck45 4y ago
    I linked https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl in another comment which links to several big players requesting full JPEG XL support. It seems the reason why it wasn't adopted more broadly is that there was no full support for it in Chrome. I wouldn't even consider it a chicken and egg situation.
    • iLoveOncall 4y ago
      Your link doesn't mention anyone asking for it. Also AVIF is more performant for most cases. Lossless is not what matters on the web.
      • ksec 4y ago
        >Also AVIF is more performant for most cases. Source? JPEG XL has already shown, over 10,000 sample size and over a wide variety of BPP to be better than AVIF, on latest JPEG And AVIF versions. AVIF, on the other hand, has yet to shown anything similar.
      • ck45 4y ago
        It contains 8 links to the Chromium bugtracker in this paragraph: However, if the enthusiastic support in the Chromium bugtracker from Facebook, Adobe, Intel and VESA, Krita, The Guardian, libvips, Cloudinary, and Shopify is any indication, it seems baffling to conclude that there would be insufficient ecosystem interest. That's why I assumed there was demand for JPEG XL.
      • pushrax 4y ago
        JPEG XL implements lossless image compression, but that's definitely not the most interesting feature. It also implements lossless JPEG recompression. So your existing JPEGs can be served with ~20% less bandwidth, without quality loss. Unlike AVIF, JPEG XL also has advanced progressive delivery features, which is useful for the web. And if you look at the testing described in the post, JPEG XL also achieved higher subjective quality per compressed bit, despite having a faster encoder.
        • 149764 4y ago
          JPEG XL supports lossless, lossy and lossless JPEG recompression. You can see lossless benchmarks against other formats here: https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/ https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp...
        • astrange 4y ago
          Lossless JPEG recompression, if it’s so good, can be done at the HTTP layer. If a new image format doesn’t have a hardware decoder it’s dead. The security surface of new formats is unacceptable if it’s going to be slow and power-hungry too. Only problem with JPEG is the lack of HDR.
          • JyrkiAlakuijala 4y ago
            JPEG XL as a HTTP Content Encoding: 1) transfer JPEG XL, 2) decode the JPEG XL to DCT coefficients, 3) encode a new JPEG1 file 4) decode the new JPEG1 file 5) render pixels JPEG XL as image format: 1) transfer JPEG XL 2) decode the JPEG XL to DCT coefficients 3) render pixels Two additional coding steps (3 and 4) are needed in the HTTP Content Encoding approach. If we want to transfer lossless JPEG1s, it is less computation and a faster approach to add JPEG XL as an image codec. If JPEG XL is too powerful and creates danger for AVIF, then one possibility is to remove features such as adaptive quantization, lossless encoding and larger (non-8x8) DCTs. This effectively makes JPEG XL as JPEG1 recompressor as an image codec. Also, JPEG XL's reference implementation (libjxl) has a more accurate JPEG1 decoder than any other existing implementation. Asking someone else to paint the pixels leads to worse quality (about 8 % worse).
      • JyrkiAlakuijala 4y ago
        Nope. In my eyes AVIF is not more performance. It makes photos suffer and become blurry, especially so in highly saturated areas, skin, marble, vegetation. Once beautiful things start to look like cheap plastic.
        • gjsman-1000 4y ago
          Check the file size - anything will look bad if you set the compression too high. If you see AVIF images with some artifacting, find a JPEG of the same image and compare file sizes. An AVIF the same size as a JPEG will be better than the JPEG - an AVIF only 50% of the size will probably be visually undetectable to most people. An AVIF only 20% of the size... you'll tell. Same for JXL - if I set my JXL to compress to only 15% of the size of the JPEG, it's hardly a fair comparison.
          • JyrkiAlakuijala 4y ago
            For my eyes: AVIF fails to deliver a consistent experience at 3+ BPP -- I'd hate to compress my family pictures at AVIF even at high BPP, some part is smudged in a weird way. libjpeg-turbo and mozjpeg does deliver a consistent experience at 4 BPP guetzli and jpegli delivers a consistent experience at 3 BPP JPEG XL delivers a consistent experience at 1.7 BPP
    • wpietri 4y ago
      Thanks for this. I looked through the big-player comments and the one I found most persuasive was from Shopify, who had specific, practical reasons for needing this: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c79 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
      • flak48 4y ago
        The reply by the Chromium engineer (from Google? - I'm not sure) to a long thread of people from several companies quantifying the benefits of JPEG XL and requesting that it be supported is just sad: > Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons: > - Experimental flags and code should not remain indefinitely > - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL > - The new image format does not bring sufficient increm ental benefits over > existing formats to warrant enabling it by default > - By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome --- If I were to put on my tinfoil hat, I would imagine the people involved here are desperate to put 'Removed unused code and removed maintenance burden by X%' in there performance reviews for this year
        • arglebargle123 4y ago
          There's not much to tinfoil hat about here, Google is killing jxl in favor of a format they control: webp.
  • hmry 4y ago
    It is supported by every image manipulation program I use on a regular basis. Photoshop, Krita, EOG, IrfanView. That's enough for me.
    • iLoveOncall 4y ago
      This is irrelevant, what matters is the consumption of the format, not its production.
      • lajamerr 4y ago
        Can't really consume it if it's locked behind a flag. 99% of chrome users never touch the flags at all.
      • hmry 4y ago
        Isn't that circular reasoning? Chrome shouldn't support JPEG-XL because not enough consumers support it? Chrome is the number one consumer of images. If Chrome added support, suddenly 90% of people would be able to use the format. (Also EOG and IrfanView are image viewers, not production tools.)
        • wpietri 4y ago
          Yeah, to me this is another sign that Chrome's dominance is a menace to the open web. Whatever the best outcome is here, it's very concerning to me that a possibly important improvement can be blocked with so little meaningful explanation.
          • arglebargle123 4y ago
            The explanation is pretty plain: google controls the webp format, jxl competes with webp.
            • quikee 4y ago
              In what way does Google control WebP? They have frozen the format and nothing will be added to it. WebP2 was abandoned. Google is also involved with JPEG XL - actually some developers that worked on WebP now work on JPEG XL. If someone controls something it is the Chromium/AOM/AVIF/AV1 team that controls and decides what multimedia formats go inside Chrome/Chromium thus controlling what is used on the web and ignoring what the web community has to say about it.
  • sitkack 4y ago
    It isn't going to be used anywhere when it is behind a flag.
  • scorpio241 4y ago
    Not used anywhere? E.g. Affinity Photo has support for JPEG XL, but not for AVIF. Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF. https://en.wikipedia.org/wiki/JPEG_XL#Official_support https://en.wikipedia.org/wiki/JPEG_XL#Official_support Official support: Squoosh – In-browser image converter[42] Adobe Camera Raw – Adobe Photoshop's import/export for digital camera images[43] Affinity Photo – raster graphics editor[44] Chasys Draw IES – raster graphics editor[45] Darktable – raw photo management application[46] ExifTool – metadata editor[47] FFmpeg – multimedia framework, via libjxl[48] GIMP – raster graphics editor[49] gThumb – image viewer and photo management application for Linux[50] ImageMagick – toolkit for raster graphics processing[51] IrfanView – image viewer and editor for Windows[52] KaOS – Linux distribution[53] Krita – raster graphics editor[54][55] libvips – image processing library[56][57] vipsdisp – high-performance ultra-high-resolution image viewer for Linux[58] Qt and KDE apps – via KImageFormats[59] XnView MP – viewer and editor of raster graphics[60] Pale Moon – web browser[61]
    • gjsman-1000 4y ago
      There's only one issue with this list - many of these applications also support AVIF, and were "sitting on the fence" over the issue, which should not be interpreted as a sign of JXL's success. And the ones that don't are very likely to fall in line after the Chromium decision.
    • masklinn 4y ago
      > Not used anywhere? E.g. Affinity Photo has support for JPEG XL, but not for AVIF. It also support PSDs. Should Chrome support PSDs? > Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF. Ah yes, Google, a major contributor to JXL, is "clearly biased towards AVIF". I'm sure you'll find your saviours at Apple (governing member of AOM, shipped AVIF this year), Mozilla (governing member of AOM, shipped AVIF in June 2020, default-enabled in October 2021), or Microsoft (governing member of AOM).
      • deleted 4y ago
        [deleted]
  • mort96 4y ago
    JPEG XL was not used anywhere on the web because no browser shipped with JXL support. As soon as Google enabled it in Chrome, Mozilla in Firefox or Apple in Safari, we would've started to see adoption.
    • JyrkiAlakuijala 4y ago
      Previously yes. Two browsers have now added support.
      • mort96 4y ago
        No? Every single browser on caniuse has either no JXL support at all or has it disabled by default: https://caniuse.com/jpegxl https://caniuse.com/jpegxl
        • lifthrasiir 4y ago
          I don't know another, but Pale Moon does support it so your original statement is just false. And it can be actually a good way to test a proposed patch to Gecko---many issues were found and fixed after it first got JPEG XL.
  • croes 4y ago
    I wonder why nobody used a hidden feature that needed to be activated manually.
  • rhdunn 4y ago
    It's not used anywhere because it is/was behind a feature flag so browsers didn't support it out of the box. IIUC, various companies like BBC, Facebook, and others were ready to deploy JPEG XL support. If you take your approach, nothing new (including the webp standard that Google/Chrome pushed) would be released on the web because nothing is using it.
    • astrange 4y ago
      WebP should not have been released and no one should have used it. Google should stop letting individual employees invent new image formats as hobbies. (This happened _twice_. WebP lossless is a whole different codec from lossy.) AVIF is the first one that might be acceptable.
      • ksec 4y ago
        I am glad I am not the only one seeing it. While in extreme minorities, still happy to be this view is not some insanity as many claims to be.
      • JyrkiAlakuijala 4y ago
        Another take on this: AVIF is a Netflix engineer quick-hacking a video format as an image format -- without actual experience in codec design, image compression or psychovisual research, without consulting such people to get the design right. When size and memory limitations were noticed, a tiled approach was proposed where globally spanning artefacts through the image will emerge. No one has been able to propose a fix for this and other kludges yet. AVIF doesn't match WebP lossless in density, even given the 10 years more of compression research. AVIF doesn't even beat PNG at lossless, which itself was hacked together in a few months ~25 years earlier (primitive filtering, mixing filter bytes with image data, botched 16 bits compression, layering a primitive 1980's byte-compressor and filtering instead of designing a codec).
  • sb057 4y ago
    WebM, VP8/9, WebP, and for that matter MP4, MP3, and the original JPEG weren't used anywhere until there was support for them.
• masklinn 4y ago
  > in hopes that Google will change their mind once the rest of the industry has switched to JXL. What rest of the industry? Apple is clearly not interested, neither is Microsoft[0], and xl weirdoes have been busting mozilla's balls for years with little progress. Even if you manage to bully Mozilla into shipping and default-enabling xl rather than just removing it, Firefox is currently sitting at an incredible 2.5% market share (and I'm saying that as a Firefox user). [0] well they obtained a patent on rANS so they might be interested in other people using it I guess, that's money in the bank: https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/
  • gsich 4y ago
    Wikimedia has 10% on Non-Input-crippled (or handicapped) devices for Firefox.
  • dieulot 4y ago
    > Apple is clearly not interested They have made no such statement AFAIK. The fact that they adopted AVIF relatively swiftly, and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two.
    • JyrkiAlakuijala 4y ago
      Apple is a company that cares deeply about usability. Once JPEG XL reaches critical mass in photography or creative work (video mastering, image processing, graphics and similar), Apple will very likely be the first to add support. Their users much rather have a thumbnail than a stock icon for photographs and graphics. I wouldn't be surprised if JPEG XL support would be announced by mid 2023.
    • pigsty 4y ago
      Apple dragged their feet on introducing webms to Safari and they still often require fiddling with to get working on iOS. If Apple isn’t jumping at supporting a format, it’s generally safe to assume they’ll do all they can to not support it unless the pressure is overwhelming. Which doesn’t seem to be the case with this format.
• bob1029 4y ago
  > I think I will continue using it with WASM polyfills This is the answer. You can also build your own application-specific codecs this way. I've been exploring a variation of jpeg/mpeg that uses arithmetic coding and larger block sizes. Virtually all of the fun patented stuff we couldn't use in the early 00's is in the public domain now.
  • lifthrasiir 4y ago
    One of the main benefits of JPEG XL is a superior progressive decoding and polyfills won't be never able to replicate that feature.
    • Sephr 4y ago
      Why do you think that polyfills can't implement progressive decoding? It's simply a matter of using <canvas> for progressive rendering.
      • lifthrasiir 4y ago
        Canvas has to retain all pixels unconditionally, unlike native images that can be unloaded from memory as needed. It is technically possible to implement all other features (using service workers or CSS Houdini), but tons of limitations apply and can easily outstrip supposed benefits.
        • supermatt 4y ago
          Can't you just read the stream and emit the images(s) as they get downloaded to be rendered in a canvas - exactly as a native implementation would do?
          • niutech 4y ago
            This is what I did with JXL.js Multithread (https://github.com/niutech/jxl.js#multithread-version https://github.com/niutech/jxl.js#multithread-version) - but instead of <canvas> I am pushing the blob to the <img>.
• mort96 4y ago
  The main reason this is sad to me, despite the existence of AVIF, is: JXL could losslessly re-compress JPEG images. There's a vast amount of JPEG images out there where the uncompressed data is long lost. Those images can't really take advantage of AVIF, since then you'd end up double-compressing the image; AVIF will do its best to re-create the JPEG compression artefacts. JPEG XL can achieve better compression ratios on existing JPEGs without this double-compression problem.
  • maria2 4y ago
    That doesn’t seem like a great reason to use JPEG XL. Existing JPEGs are meeting the needs of their users. Sure, maybe those images could be ever more compressed, but it’s clearly not a deal breaker otherwise those images wouldn’t have been JPEG encoded in the first place. Second, the amount of existing JPEGs [that people care about] will decrease over time, both in quantity and as a portion of the total image population. So lossless re-encoding is a solution in search of a problem.
    • mort96 4y ago
      Over the past 30 years, JPEG has been the best generally available compression format, and it's what consumer cameras generally use to store their photos. I'm not sure what you imagine people would have used instead if storing images efficiently is "a deal breaker". As for the amount of existing JPEGs that people care about decreasing over time: This might eventually become true, but only to a point. People's existing photo archives are generally all JPEGs. People care about even (especially?) the older images in their photo albums. And it will take a long time before everyone is adding exclusively AVIF-encoded rather than JPEG-encoded images to their archives.
      • maria2 4y ago
        Does re-encoding JPEGs as JPEG XL really unlock anything new? The answer is likely no. So this case is not useful to optimize for. As for people's photo albums. The iPhone is already storing new images in HEIF, so JPEGs are becoming less relevant with each passing day. And of course, you can still view the old images perfectly fine as JPEGs.
• greggarious 4y ago
  Was it patent encumbered?
  • ksec 4y ago
    From the views of ISO, JPEG Committees, no, they are not patent encumbered. From the view of AOM members or supporters, yes they are or at least not clear.
    • greggarious 4y ago
      >From the view of AOM members or supporters, yes they are or at least not clear. Sounds complicated. Why not PNG? :-)
      • rezonant 4y ago
        PNG, while being a very nice format, is dramatically larger than JPEG, JPEG-XL, AVIF, HEIF etc. For multi-megapixel images that size cost adds up.
      • masklinn 4y ago
        PNG is really bad for anything photographic. As in, it's pixel-perfect, and the images are also absolutely enormous, unusably so.
    • jonsneyers 4y ago
      Do you have any sources on that? And who would be the one making any claims relevant to JPEG XL or asking for royalties? Because I have not seen anyone other than Cloudinary and Google declare to have patents relevant to JPEG XL, and those two parties have explicitly granted royalty-free licenses. So to me the situation is as clear as it gets. Of course it can always happen with anything less than 20 years old that a patent troll appears and makes claims. This has not happened yet though in the case of JPEG XL.
• matheusmoreira 4y ago
  > I think I will continue using it with WASM polyfills Images that can't be displayed without Javascript. Incredible.
  • hirorpt 4y ago
    I live in a world where Javascript is disabled by default, but I already see many sites where images are not viewable. In the case of JPEG XL, the alternative is to use Firefox and enable the flag, so unlike these sites, the claim that the images cannot be viewed unless Javascript is enabled is not valid.
  • niutech 4y ago
    You can use <picture> element for a JPEG/PNG/WebP fallback.
  • speedgoose 4y ago
    While you need some little JavaScript to initialise it, WebAssembly isn’t JavaScript.
    • hypertele-Xii 4y ago
      That doesn't counter the fact that it's an image that won't display without JavaScript.
      • speedgoose 4y ago
        True. The very very few people who disabled JavaScript will have to add some more websites to their allow list.
        • dmitriid 4y ago
          It's not the "very-very few". It's the combined population of several large countries. Because you're immediately excluding people on old devices, on underpowered devices, on devices on bad networks, on devices with weird/incomplete/glitchy/limited support for what you need, sites where JS just errors out (and dies, because there are no recovery options if there's a global JS error)... And the list just goes on, and on, and on. The inability of developers to look beyond their latest-and-greatest dev machines with unlimited power and everything under the sun enabled is just mind boggling.
• ddevault 4y ago
  JXL had this coming. They should have written specifications. The implementation can never be the standard. I hope everyone watching this learns from their mistake.
  • lifthrasiir 4y ago
    I don't know where you did get that impression but JPEG XL has written specifications which is exactly the standard.
    • ddevault 4y ago
      Have you actually tried to read them? They don't exist. https://jpeg.org/jpegxl/ https://jpeg.org/jpegxl/ https://jpeg.org/jpegxl/documentation.html https://jpeg.org/jpegxl/documentation.html All we have is a whitepaper.
      • lifthrasiir 4y ago
        I'm the author of the first independent reimplementation of JPEG XL [1] and I have definitely read all of them. Do you want to criticize the lack of openly available standards? In which case developers have given recent (and generally better) drafts to anyone interested so it's practically open, though a formal action by JPEG would be more desirable. [1] Previously on HN: https://news.ycombinator.com/item?id=32885509 https://news.ycombinator.com/item?id=32885509
        • ddevault 4y ago
          I'm going to say this as politely as I am able: closed standards can eat a big, steaming plate of shit. If it's not open, it doesn't exist. Period.
          • ksec 4y ago
            Sorry Drew, disagree here. But also not surprised. Open Standard does not mean Free Standard. As much as I would want the Final Spec 1.0 to be freely available.