7 ms·

The case against JPEG XL

• computerbuster 20d ago
  I'm the author if anyone has questions – AMA
  • adzm 20d ago
    Lossless was discounted due to webp, but doesn't webp lossless only use 8bit depth RGB? (I think it is important to have a separate file extension for lossless stuff anyway, otherwise it gets confusing quickly)
    • computerbuster 20d ago
      Lossless was discounted because lossless just isn't very useful on the Web
      • dylan604 20d ago
        I can tell you that I don't care if the AI slop used in everyone's AI generated blog is lossy compressed. In fact, expecting it to be of such import that lossless is required is pretty farcical.
      • F3nd0 20d ago
        It may not be as widely used as lossy, but it does have valid uses that lossy just can’t substitute and the web needs to accomodate for. And the space savings offered by JPEG XL seem pretty great in that regard. ‘The average Web consumer’ may not need lossless, but a non-negligible minority very well might, hence why lossless should absolutely be on topic.
        • computerbuster 19d ago
          JPEG XL isn’t consistently better enough to justify it. If lossless is so important, maybe we should be campaigning for HALIC.
          • F3nd0 19d ago
            Isn’t HALIC proprietary? JPEG XL is an open format with a libre reference implementation, usually compresses better than WebP/PNG, and supposedly has plenty of room for improvement still (in said implementation). Add to that its versatility in other areas and the fact that it seems to have generated widespread interest (much unlike WebP in its time, from what I recall), and I think campaigning for it makes perfect sense.
      • SmasherEpilepti 20d ago
        I'm active in many art communities on the web for whom being able to view and share lossless images are table stakes. Also many other communities for which being able to view and share lossless screen captures is fundamental. I can accept a claim that JPEG-XL is not the best format for it, or that it is good, but not worth the complexity and extra surface area it introduces. I can not accept a claim that "lossless just isn't very useful on the web".
        • bawolff 20d ago
          What percentage of the web is that 0.1% ? 0.01% ? I think its correct to say a use case that is very niche on the web isn't super important to the web. Especially when there already exists a bunch of lossless formats. After all, the value proposition of jxl is to save some bytes. It would be different if the point was introducing images as a whole.
          • out_of_protocol 20d ago
            count .png-s in the web. There's a lot. And .jxl's lossless is much better than png's. Basically any image with sharp lines (screenshots, image of a button etc) or gradients should be lossless.
            • jaffathecake 20d ago
              This is outdated thinking. AVIF is really good at sharp lines & gradients. https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/#:~:text=Another%20example%20is%20a%20screenshot%20of%20the%20Interop%202025%20scores https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/#:~...
              • F3nd0 19d ago
                Not at lossless, though.
          • SmasherEpilepti 19d ago
            If you're counting by absolute numbers, 90% of the web is probably YouTube, Facebook, Instagram, Twitter, Bluesky, Reddit, TikTok and the other major silos. I don't think those should be able to define all the web technologies for everybody else. > Especially when there already exists a bunch of lossless formats. Sure, but I'm not defending JXL here in particular, just arguing against the point that lossless images are unimportant on the web.
      • slimbuck 20d ago
        Perhaps niche compared to the entire web, but we use lossless webp for gaussian splat data delivery for realtime rendering. (https://developer.playcanvas.com/user-manual/gaussian-splatting/formats/sog/ https://developer.playcanvas.com/user-manual/gaussian-splatt...). Scenes often comprise gigabytes of lossless webp, some of which you can see at https://superspl.at https://superspl.at.
        • slimbuck 20d ago
          We could get better compression using a custom encoder, however with webp the browser decodes off the main thread, copies the resulting data to GPU memory and caches the images for us. All very useful on the web!
  • pkulak 20d ago
    We have to apply some weight to the fact that one is open, one isn't, right? EDIT: Oh! Of course. AVIF is based on AV1. For some reason I was thinking HEIF the entire time I was reading the article. Man... withdrawn! Really good read, btw. Very good points.
    • abhinavk 20d ago
      Both are open I think.
    • computerbuster 20d ago
      AVIF is royalty-free, & SVT-AV1 and libaom are open source. Edit: saw you corrected. Much appreciated!
      • dannyw 20d ago
        SVT-AV1 is also more than just open source in name only; development and discussions happen in the open; with many community forks that’s now getting upstreamed/merged. It is a true open source project; not just an open source license.
        • computerbuster 20d ago
          SVT-AV1-PSY was the first fork, and I created it. When the project matured, the maintainers reached out directly to get things merged – I can confirm it is a great project with great people who are very easy to work with.
    • gsnedders 20d ago
      AVIF _is_ AV1 in the HEIF container. (.heif is sometimes used as a file extension generically, but HEIF is itself a container that can support various payloads.)
  • vlmutolo 20d ago
    What do you think the best use cases for jxl are? Where does it still have an advantage over other formats?
    • computerbuster 20d ago
      I think it is a potentially good camera format, good medical & scientific imaging format, good RAW compression format (Apple uses it in some newer iPhones for this), good media interchange formats for tools like Photoshop (think about storing all of your layers inside of one JPEG XL that's fully compatible with .psd files), and more. It is incredibly expressive and versatile, which is what makes it so risky on the Web.
      • SmasherEpilepti 20d ago
        It's a great option for 3D art texturing and compositing. I could see using it over OpenEXR, which I use a lot in Blender right now.
  • rmunn 20d ago
    I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases. Would you agree? The scenario I'm thinking of is sending a photograph by email. Let's say Sally has just had her second baby, and wants to send baby pictures to her mother, the baby's grandmother. Neither Sally nor her mother are computer professionals, and they don't want to care about image formats. Sally wants to upload a file from her camera, attach it to an email, and send it. Her mother wants to click on the email and see pictures of her new grandchild. Neither one of them wants to have to convert the image themselves. Let's say it's a few years in the future and Sally's camera produces JPEG XL files by default. (Which I don't think would happen if browsers didn't support it, for exactly the reason I'm about to articulate). If Sally's mother's browser doesn't support displaying JPEG XL, then although Sally (who uses a different browser than her mother) sees the picture in the email when she sends it, her mother writes back an email saying "the picture didn't show up, can you resend it?" And they spend a few back-and-forth emails before finally getting tech support from a friend who helps Sally convert the picture to old-school JPEG so her mother can see it. If that's the experience for end-users, cameras would hesitate to switch to JPEG XL as a default format. Because nobody wants a hostile review from a user saying "My mother couldn't load my baby pictures, what kind of lousy camera are you making?" So even if it's not the best format for the Web, I'm still persuaded that having universal browser support for a format intended for photos is an important factor, and devices like cameras will not switch to it as a default format until manufacturers are certain that browser support (and OS support, and electronic photo frame support, and so on) is nearly universal. None of that takes away from the argument "Other image formats are better for saving space on the Web", which is the main thrust of your post. But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow. What are your thoughts on that argument?
    • computerbuster 20d ago
      > But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow. I'm not even personally convinced it is useful for cameras. Sally's situation isn't particularly bandwidth or feature-constrained, so JPEG or PNG work. Maybe JXL is solving problems that don't exist?
  • wmf 20d ago
    I have a lot of basic questions about the CVVDP graph. Is the X axis encoding or decoding speed? Is higher better on the Y axis? What format is Aperture? I assume "aom" is AV1 but it wouldn't hurt to document it.
    • computerbuster 20d ago
      x-axis is encoding speed, Y-axis is BD-rate where higher is better. aperture-alpha is an upcoming encoder from Halide Compression, no more details than that. libaom and SVT-AV1 are both for AVIF; libaom is the AV1 reference encoder.
      • KingMob 20d ago
        > where higher is better Bit of a nit, but can you add that as a note to the legends/graphs in the future? As a layperson, it helps us to orient to graphs with unknown metrics. Thanks for the article, btw!
        • computerbuster 14d ago
          Will do going forward, thanks for the feedback!
      • a-french-anon 20d ago
        Wait... SVT-AV1 doesn't support anything else than 4:2:0, right? Kinda biases the comparison here.
        • computerbuster 14d ago
          Why does that bias the comparison exactly?
  • aidenn0 20d ago
    How ergonomic are the modern AVIF encoders? I like libjxl (and cjpegli) because they are really good at generating reasonably compact, high-quality images. For every other image encoder I used I couldn't find one setting that would make compact, high-quality images across the gamut of inputs (e.g. things like comics that have extremely visible high-frequency content would look terrible at quality settings that looked good for many photographs).
    • jaffathecake 20d ago
      Have you tried the latest AVIF encoder? It's quality setting seems much more stable.
      • aidenn0 19d ago
        I have not tried them; I thought that was clear from my wording.
  • kinesin 20d ago
    What about the current AV1 patent issues, like Sisvel/Access Advance and Dolby vs Snap? Does that change the AVIF vs JXL comparison at all?
    • adgjlsfhk1 20d ago
      those issues aren't real. they're nuicense suits by a patent troll. a couple companies will settle cause it's easier and cheaper, but if they ever try to go after someone big they'll fight it and get the patents invalidated for covering 30 year old work
  • rodarmor 20d ago
    Very compelling and thoughtfully written article. Thank you!
  • a-french-anon 20d ago
    What do you think about the fact that most perceptual quality improvements in SVT-AV1 have been almost only driven by external, non-paid enthusiasts such as yourself while the maintainers have been basically only targeting VoD and RTC? Compared to JXL (which admittedly has almost nobody working on except veluca these days...) which was focused on it since the beginning, I think it really matters.
  • vasilvv 20d ago
    It would be nice to see the actual R-D curves for the codecs instead of compressing them into a single number. Also, what is BD-rate computed with respect to, jpegli at p0?
  • xigoi 20d ago
    What format would you recommend for archiving photos if I don’t mind slight quality loss?
  • F3nd0 19d ago
    Thank you for an interesting article. You’ve helped AV1 come a long way! In the ‘Lossy Compression Efficiency’ section, you compare the codecs using various metrics, but I don’t think you say anywhere what quality the images were encoded for. Did you forget to mention that or am I just reading things wrong? (I assume BD-rate tells us how similar the images look, but I also assume the values would change if the encoders were made to target different qualities, hence why the intended quality seems quite important to know.)
• Feathercrown 20d ago
  "For non-photographic images, the argument that “they should be vector images” doesn't hold up because many images could be vector images but aren't, and they can't be vectorized perfectly. “The world should be different” is not a justifiable defense against optimizing for the way the world actually is." This is a good paragraph. I see people forget to apply that last sentence all the time.
  • karim79 20d ago
    Agreed. JPG is the most popular format for photography. PNG, the lossless format is great for diagrams and stuff with sharp edges. It can be "compressed" via dithering and quantization. GIF is there... because it will always be there because it's just a hit that will never go away. It's also lossless (when discounting colour depth). The new formats are interesting webp, avif, JXL and so on. Jpeg classic is the clear winner IMHO and will probably never be less relevant than the new fancier formats. JPG even does text and sharp edges, reds, and so on well if you tell your process to take into account chroma subsampling! It's magic and it puts food on my table.
    • Gigachad 20d ago
      Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound. Modern video formats are so much better that they are a no brainer to use while the word gif just got used to refer to looping video without sound rater than the literal gif image format.
      • karim79 20d ago
        Precisely. Kind of reminds me of "Hoover" or "Kleenex". Coca cola even. It has brand equity which means it's not going away any time soon.
      • vohk 20d ago
        Reminds me of when Imgur started trying to push changing gifs over to gifv, which were just mp4 with a strange new file extension. I didn't like their approach but it really was such an improvement on file size and quality.
• vkaku 20d ago
  We all know these aren't purely technical reasons, it's to break the monopoly of one Internet Company's decoder format portfolio. You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.
  • computerbuster 20d ago
    AVIF is royalty-free, with open-source implementations not developed by Google. Google's implementation is libaom; as you can see, SVT-AV1 beats it. SVT-AV1 is developed by a number of companies – historically Meta, Netflix, Intel, independent contractors, and others. I worked on SVT-AV1 myself. I don't see how this is a bad thing for everyone, even if Google drove standardization of AV1?
    • derf_ 20d ago
      There were something like 40 companies involved in AV1 standardization. Quite a few technical contributions did not come from Google, and quite a few of Google's proposals were substantially modified by feedback from others before they were included (and not all of them were eventually included). Source: I lead Mozilla's technical contributions to AV1.
      • juliobbv 20d ago
        It saddens me to see discourse on the internet about AV1's ancestry being focused on Google's VPx line of contributions, while diminishing those coming from Daala (entropy coder...) and Thor (QMs...), as well as inter-company collaborations (CDEF). A redeeming outcome is that with AVIF's new image tuning modes (both in libaom and SVT-AV1), Gianni and I managed to utilize as many AV1 coding tools as possible, including QMs that sorely needed a well-deserved spotlight. Also, thanks for paving the way to the current state of multimedia compression! I'm a longtime fan of Xiph(ophorus) since the 1.0 beta/RC Vorbis days. We used your image sets a lot during our testing.
        • derf_ 19d ago
• adzm 20d ago
  I didn't realize progressive AVIF was a thing recently either; the comparison between that and jxl was pretty surprising.
  • nneonneo 20d ago
    Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.
    • est 20d ago
      Perhaps it's just a bad example. I suppose avif can support multiple "scans" of progressive encoding as well.
    • computerbuster 20d ago
      I believe wholeheartedly that AVIF's approach is significantly better UX.
      • oofdere 20d ago
        What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
        • juliobbv 20d ago
          The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
• nneonneo 20d ago
  That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer. It is, however, an incredibly cool demo of what the format is capable of. I'm not completely sure if an image format should be that flexible, but I'm impressed nonetheless.
  • est 20d ago
    I wonder if similar hacks apply to zlib and .png as well.
    • nneonneo 20d ago
      Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
      • tacomagick 20d ago
        The infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
        • nneonneo 20d ago
          The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers. In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
• sroussey 20d ago
  All my photos are HEIC. Why not just use what I have and not translate?
  • computerbuster 20d ago
    Think about how many images large platforms deliver every day, and the benefits of saving bits on each of them.
  • kalleboo 20d ago
    HEIC has a very messy patent situation around it which limits what tools work with it. E.g. for official Windows support by Microsoft you need to buy the codec from the Microsoft App Store for $0.99
  • lern_too_spel 20d ago
    Formats that aim to be web standards should try not to be patent encumbered. There was a lesson to be learned from the Unisys debacle in the 1990s. If you don't want to reencode for the web, use a device that captures in a format that can be shared on the web.
  • Gigachad 20d ago
    You should never transcode lossy source files because there is generation loss in quality. There is still a lot of reason for Apple to switch from HEIC to JXL for photos going forward since HEIC is patent encumbered so it will never see widespread use.
    • dimatura 20d ago
      Well, JpegXL does have one really cool feature: you can transcode jpeg to jpegxl (and back) losslessly. For jpeg to jpegxl it'll save something like 15-20% in size.
      • Gigachad 20d ago
        This is probably going to be a key feature for web platforms. They can convert their massive backlogs to jxl for free space savings.
• joeblubaugh 20d ago
  If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc? What does it offer there that existing workflows can’t support? Do those advantages make up for the transcoding that every web publisher would need to do to make the outputs useful on the web?
  • dannyw 20d ago
    I’ve been shooting with semipro to pro cameras for decades across brands, and I haven’t came across a single camera that supports shooting JPEG XL. HEIF is what is getting support in recent models; but JPEG still rules supreme for its compatibility.
  • computerbuster 20d ago
    Web publishers should definitely be stripping metadata at least, and transcoding isn't much harder. For anyone who cares about bandwidth, transcoding to efficient formats is non-negotiable; if you don't, then why do anything? Just ship PNG, who cares? I think one of the compelling use cases for camera manufacturers would be an interoperable format for editors. Since JXL has support for so many channels, you could load your image into an editor, edit it, add layers, etc., and export as JXL, which could be used for other things.
    • kps 19d ago
      > Web publishers should definitely be stripping metadata at least No, they shouldn't. Not blindly. Metadata can include copyright license information, such that stripping it violates the license to reproduce the image.
  • pwg 20d ago
    > If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc? I suspect that eventually, the browser makers that are reluctant to add JpegXL support will do so, even if reluctantly, and so it will eventually "become useful on the web". The reason why is Adobe added JpegXL as a compression format for PDF's, and as every browser maker wants their browser to also be a "PDF viewer", this means they must include a JpegXL decoder to be able to support PDF's going forward. If they must have a JpegXL decoder anyway, it is not that difficult to also add it as another supported format for the <img> tag.
• dmix 20d ago
  I wasn't really sold on the argument initially, given they admit there's some real lossless usecases, but this is a good bit from the conclusion: > Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere – it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL. Especially when JPEG XL doesn't appear to add anything to the Web platform. It is very annoying downloading an image for the web and then trying to upload it somewhere else also on the web during these transition periods.
  • computerbuster 20d ago
    There exist lossless use cases, for sure. I think most people would be well-served by high-fidelity lossy that saves a lot of bits while still looking perceptually identical. Whoever isn't served by that most likely doesn't care about size savings, and can stick with lossless PNG.
    • account42 20d ago
      The problem with that is that the idea many stakeholders (especially big platforms) have of "perceptually lossless" is actually compressed to hell garbage. The only way you as a user can ever guarantee actually perceptually lossless is to use a fully lossless format.
• Dwedit 20d ago
  Much like WEBP, JPEG-XL is two different codecs in one. There's VARDCT mode, and Modular Mode. Modular Mode is normally used for lossless, but it can also be used for lossy as well. When you use Lossy Modular Mode, you get different kinds of compression artifacts than what you'd see in a JPEG file. For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins) For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.
  • computerbuster 20d ago
    Lossy Modular isn't efficient enough to compete with even JPEG. Also, look at the graphs – Iris-WebP beats JPEG XL.
    • a-french-anon 20d ago
      Sorry for the dumb question, but I don't understand something in these graphs. Since it's x=speed and y=bd-r, is this test done at a fixed target quality/size?
• aniviacat 20d ago
  > Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over. This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail. Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.
  • edflsafoiewq 20d ago
    Does the difference matter?
    • aniviacat 20d ago
      The difference matters, as it means that AVIF's "progressive decoding" serves no technical benefit and is only a minor ergonomic benefit: On a website, you could achieve the same effect simply by layering two <img> elements on top of each other, one with the thumbnail and one with the final image. If layering to <img> elements is fine for your use case, then it simply means you have no need for progressive decoding.
    • cpburns2009 20d ago
      Progressive rendering is just a different way to layout the pixel data. Embedding a thumbnail is storing two distinct images. In other words, progressive rendering should be more efficient space and bandwidth-wise.
      • edflsafoiewq 20d ago
        The DC coefficients in a progressive JPEG are literally an embedded thumbnail (a 1:64 copy of the original) right? Is the question if the second "layer" replaces the thumbnail or layers corrections on top of it? It wasn't clear to me which AVIF does.
• F3nd0 20d ago
  It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs. That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.
  • computerbuster 20d ago
    It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.
    • F3nd0 20d ago
      > It is getting its try, actively, in libjxl. That’s the thing, though: libjxl development hasn’t seemed all that active in recent years. The community contributors you mention seem quite far from driving the development, and some of them say that the usual devs have been busy with other projects (including jxl-rs as of recently). > People like to pretend AV1 got infinite resources I would not suggest that, but in another comment here you yourself say that SVT-AV1 (which you compare to JXL favourably in your article) has seen active involvement from ‘Meta, Netflix, Intel, independent contractors, and others’ – not to the community fork SVT-AV1-PSY and its successors contributing their improvements back upstream. I can believe that JXL may very well be more difficult to work with, but am I wrong to assume you’ve been able to continuously focus on your own encoder (and apply your experiences from your earlier work on SVT-AV1)?
• eviks 20d ago
  > and narrowly scoped to the needs of the Web > it was hard enough to get widespread WebP adoption That's not a coincidence! And because these newer codecs are better outside the Web, it's not really "the same hill"
  • computerbuster 20d ago
    In the post, I say "I think WebP was a bit too narrowly scoped" This is not a coincidence, but I don't think it was that devs looked at WebP and thought "huh, the lack of 4:4:4 and 10-bit support makes this less compelling for our product despite being all over the internet" – I think it was just a matter of not keeping up. Except for Apple, not sure why they took so long to implement it.
    • F3nd0 20d ago
      Wasn’t WebP pushed pretty hard by Google for several years, until the (ever shrinking) rest of the ecosystem sort of caved in? My impression was that there wasn’t much interest until it became more or less inevitable because of that.
      • mitxela 20d ago
        That's correct
• TheSpacerr 20d ago
  Interesting.
• mzmzmzm 20d ago
  I feel like JPEG XL could be a good RAW format for mirrorless cameras... something with huge flexibility but with the perk of being easier to view casually on other devices. And then that in turn could make it a more useful web format? Camera vendors are of course notoriously proprietary/stubborn.
  • adgjlsfhk1 20d ago
    it's even flexible enough to represent images pre de-bayering
  • pkulak 20d ago
    Raw isn’t an image though, it’s pre-image. And we have an open raw format already. DNF I think. With pretty decent adoption.
    • weinzierl 20d ago
      True. I would love to have lossless images (and video) out of my devices still. Not as a replacement for RAW but as a middle ground between RAW and lossy JPEG. Not for quality reasons primaily but because keeping the first stages of the processing pipeline and the archival branch lossless solves some headaches.
    • Gigachad 20d ago
      You are thinking of DNG which is more of a container format. It can use multiple image formats internally to record the actual image, one of them being JPEG-XL. iPhone raw images are actually a jpeg xl inside the DNG.
  • mikae1 20d ago
    Just demosaiced JPEG XL? That's not raw. Lossless JPEG XL is in the DNG spec since three years (v1.7). So, you can convert your proprietary camera raw files to smaller ISO standard compliant JPEG XL compressed DNG raw files (mosaiced, not linearized).
    • mrngld 19d ago
• SmasherEpilepti 20d ago
  Nobody has brought it up yet, but JPEG XL seems to be close in potential and flexibility to OpenEXR. It seems more a competitor to something like that--for use in image processing and digital art pipelines--than something like JPEG, WEBP, or PNG. That said, I have converted my personal JPEGs to JPEG XL, because you can losslessly convert back and forth between the two for smaller filesize in JPEG XL with no quality loss, so I get free storage savings and can get the byte-for-byte original JPEG back if I need it.
  • doodlesdev 20d ago
    I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even more the fact this format hasn't been adopted widely yet.
    • magicalhippo 20d ago
      JPEG is a lossy frequency-space compression stage followed by a lossless Huffman coding stage. The second stage is quite generic as such, essentially compressing a stream of bits. So you can relatively easily replace the second stage with something better. And since it's lossless you can easily go back. Dropbox[1] and others have exploited this for reducing storage requirements, converting back on-demand so the client doesn't notice. https://github.com/dropbox/lepton https://github.com/dropbox/lepton
    • jbverschoor 20d ago
      byte-for-byte identical file actually. Not just imagery. You can basically save 30% without loosing ANY bit of the original file
    • jaffathecake 20d ago
      Because what you save in terms of storage, you pay for in decode time, which is an important consideration on the web.
      • doodlesdev 19d ago
• Daiz 20d ago
  A potentially major issue I have with AVIF is that because it is based on a video format, any hardware decoding support AVIF will get is likely to be restrained to common video scenarios. This can result in eg. only 4:2:0 YUV being supported by hardware decoders, as that's the upper limit of AV1 Main Profile (and thus the limit of AVIF Baseline Profile). And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc). I would not be very happy about a web where lossy 4:4:4 image compression would be heavily discouraged with modern formats. Also, good lossless compression absolutely does matter for the web as well. Lossy images just cannot be used in all circumstances - like when comparing compression quality (especially of videos), for example! EDIT: To give an additional example, pixel art is an entire field of art (which is very much still active today) where both lossless compression is a must and where 4:2:0 would be absolutely catastrophic for quality.
  • torginus 20d ago
    I'm not super familiar with AV1/AVIF but I do have extensive experience using h264 for desktop streaming, and all major implementations support 444 in hardware and software, and I doubt more advanced codecs/image formats have a limitation like this. Asked ChatGPT and it also claimed there's no problem with 444 and AVIF/AV1.
    • lgkrnkglwn 20d ago
      Then chatgpt missed an obvious issue, nvidia definitely have had shortcomings in the hardware implementation of coder/decoders only supporting 420 in nvenc/nvdec. One obvious problem with that was that it affected premiere.
      • torginus 20d ago
        We have been using NVENC with 444 and h264 in production going back years and HW as old as Turing. But it turns out you are right, 444 decoding with H264 doesn't seem to be supported up until recently: https://developer.nvidia.com/video-encode-decode-support-matrix https://developer.nvidia.com/video-encode-decode-support-mat... Never noticed, seems like a strange omission, but in any case doesn't seem to apply to newer codecs like AV1.
• hn_submit 20d ago
  I agree that the choice for JPEG XL is mostly politically motivated: it isn't Google. And its name is derived from JPEG, which is an IETF standard which gives it more clout.
  • charcircuit 20d ago
    >it isn't Google. It is Google. The JPEG XL standard evolved from a codec Google made, Google was involved in the standardization process, and Google heavily contributed to the reference implementation of JPEG XL. https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf Editors: Jyrki Alakuijala – Google, Switzerland Jon Sneyers – Cloudinary, Belgium Luca Versari – Google, Switzerland Jan Wassenberg – Google, Switzerland
    • hn_submit 20d ago
      Yes, but unlike WebP it wasn't exclusively designed and developed by Google. That's a big difference.
      • mimasama 20d ago
        AV1 wasn't also exclusively designed and developed by Google. Chrome's team should be blamed for favoring AVIF over JPEG-XL, not Google entirely.
    • jbverschoor 20d ago
      And Google also removed jxl support in Chrome in '22 (only to put it back in recently)
      • jaffathecake 20d ago
        It was only ever supported behind a flag. Stuff behind a flag isn't 'supported', it's experimental. The experiment ended.
  • ButlerianJihad 20d ago
• IvanK_net 20d ago
  Note, that JPEG XL was added as a possible compression method for DNG files (Digital Negative - stores raw images with raw sensor data of a camera). Because of it, for the past couple of years, all new iPhones and almost all Android phones (mostly Samsungs) already contain a JPEG XL encoder / decoder (to generate these DNGs).
• IshKebab 20d ago
  I'm sure this is right about all the technical things, but the stuff about the requirements of a format for the web misses the mark IMO. Normal people don't pick an image format based on whether it is suitable on the web or not. They want a format that works everywhere. If I download or upload a photo I don't want to have to do a lossy format conversion. If I'm writing an image processing tool it would be great if I can make it just support one input format that everyone uses, rather than "web" formats and "non-web" formats. So I think a large part of the attraction of JXL is that it is a single format that works both for 10000x10000 lossless scientific images, and for 256x256 lossy web photos. You don't have to be an image format expert any more. Just always use JXL. Definitely a shame about the technical flaws listed here though - especially decode time.
  • jaffathecake 20d ago
    Professional web developers want to create a great experience for their users, so they go beyond simply serving whatever comes off a digital camera. As the article identifies, JPEG XL is kinda bad at certain types of images, whereas AVIF does well across the board, so if you feel compelled to pick a single format to use, AVIF would be a better choice, but it's definitely worth optimising your web images for the web. Also, JPEG XL is two codecs bundled into one, VarDCT and Modular. So, even if you're picking JPEG XL as "the one codec", you're actually picking two, and you need to choose between them at encode time.
    • IshKebab 19d ago
      > Also, JPEG XL is two codecs bundled into one, That's an internal detail that doesn't really matter to anyone outside library implementors, or when you're choosing encode settings though. It's the same in Opus. Technically it's two formats, but as long as they're one entity that's either supported or not supported, everything is good. AVIF does seem to have at least a couple of downsides compared to JXL like max 12-bit depth, no JPEG reencode and worse recompression stability. I think they probably could have added those though, and then we wouldn't have yet another format to support for eternity. Oh well, they had their chance.
• meinersbur 20d ago
  > I believe Web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the Web. The post downplays the usefulness of versatility. I disagree. I'd prefer not to play the "which image format is best for this image and this use case" game and having to transcode between them. For instance, it would be great if I could have an HTML gallery showing pictures of my files as I store them on harddisk. Today these are JPEG, because it's the lowest common denominator. WEBP, AVIF are not supported photography tools (e.g. https://support.captureone.com/hc/en-us/articles/360002629217-File-formats-for-processing-and-export https://support.captureone.com/hc/en-us/articles/36000262921...) and I don't expect support to ever be added since it is not formats intended for photography.
  • jaffathecake 20d ago
    I personally find AVIF more versatile. I just throw images at it, and it does a great job. As the article identifies, JPEG XL performs worse than AVIF in general, but it's particularly bad at things like illustrations and screenshots. With AVIF I don't need to worry about that.
  • Pikamander2 20d ago
    I've always found it annoying how most cameras only let you save their photos as some combination of JPG/PNG/HEIC/RAW, often without any adjustable quality settings or option to save several copies in different formats. It would be great if their behavior could be customized in a more modern web-friendly way, like "Save the original photo as a 95% quality AVIF in this folder, and also as an 70% quality resized WebP in this other folder".
    • mrngld 19d ago
      The camera's I've owned (Canon and, in more recent years, Olympus/OM System) all could do RAW, JPG, or RAW+JPG, or in some cases cRAW+JPG, with several quality settings available for the JPG side. But remember, on a camera you're wanting to maximize battery life, image quality and certain key performance metrics. The OM-1 Mk II can burst up to 120fps of 20 megapixel images with locked focus or 50fps with continuous AF. Thats a huge amount of data to capture, process and write to media. I think we want cameras to optimize for that. It's trivial to dump the resulting files on your computer and then convert between formats to your hearts content.
• bob1029 20d ago
  I like how every time we have a codec fight no one seems to care very much about how long it takes to encode these files. Like I get it, the amortization schedule often works out, but there are scenarios where images need to be generated dynamically and will only ever be downloaded once. It's very hard to beat the encoding performance of libjpegturbo, even with an asic.
  • jaffathecake 20d ago
    Encoding time is one of the things that JPEG XL has claimed over AVIF for years, but in the latest encoders, it doesn't seem to be the case.
  • SideQuark 19d ago
    > It's very hard to beat the encoding performance of libjpegturbo, even with an asic. Pretty much any platform with a hardware jpeg encoder beats libjpegturbo. So probably all smart phones, large scale CPUs, even tiny few $ microcontrollers like ESP32's have hardware encode/decode that outperforms libjpegturbo.
    • kasabali 19d ago
      Sure, if you ignore PQ completely. Not that libjpeg-turbo is pinnacle of quality but hardware encoders, seriously?
      • SideQuark 18d ago
        If you want to move the bar to quality for your strawman, then libjpeg-turbo is not even close in image quality to plenty of encoders, such as jpegli crush it. For compression size it also loses to modern libs. There is no metric that libjepg-turbo wins at nowadays, not even speed. Then, if you care to learn, there are extremely high quality, lkely far beyond old software like libjpeg-turbo, use in DoD projects, satellites, medical imaging systems, commercial cameras systems, and plenty of companies that sell such chips and IP to embed in ones own ASIC. There is zero technical problem taking an opensource project, turning that exact code into an ASIC or VHDL one can put into any ASIC, an so the best ideas are reused in hardware all the time. Alma Technologies, CAST, intoPIX all sell such cores that are integrated throughout the industry, embedded everywhere, and can be bought with an ever improving host of features.
• orbital-decay 20d ago
  [dead]
• jl6 20d ago
  The chart showing jxl-rs taking 1209ms to decode a 5456x3632 image in a single thread is a little damning, but is there an equivalent benchmark showing multithreaded decode performance? Clients tend to have an abundance of threads these days.
  • jaffathecake 20d ago
    The time would be less, but you still need to power those cores. Single thread performance can be a good indicator of what it'll do the battery on your phone.
    • janwas 18d ago
      Not at all. CPU power is proportional to frequency^2. Running on 4-6 little/efficiency cores (which are widespread on mobile) is likely faster than one big core, and uses less energy.
  • janwas 20d ago
    Something is fishy here. The JPEG XL report [1] measured between 240-270 Megapixels/s on 6 cores using the C++ implementation (disclosure: I was responsible for its SIMD/threading), about twice as fast as the then-current libaom. Measuring on a single core is deeply misleading because our code was designed to scale well. I believe AVIF requires tiling in order to parallelize, which causes artifacts at tile boundaries. [1]: https://arxiv.org/pdf/2506.05987 https://arxiv.org/pdf/2506.05987
    • spider-mario 19d ago
      It’s a measurement error: the `hyperfine` command uses `jxl_cli --speedtest` which, by default, does a warmup run that ends up in hyperfine’s measured time.
    • xfs 19d ago
      jxl-rs is single threaded. It may be not a good idea to use many threads per image as one page can have many images.
• cbolton 20d ago
  The article makes a good point: JPEG XL is amazing but not specifically for the typical Web use cases, compared to AVIF. But the conclusion doesn't follow. Having an excellent and versatile format supported by browsers is very useful! Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% longer decode, and maybe the website doesn't need very high resolution images or more than 12 bits per channel. But my personal archives can definitely use that and it's great that such files can be viewed everywhere without specialized tooling, including served on the intranet and indeed the Web. In summary JPEG XL easily beats AVIF on the not-so-long tail of use cases and having compatible viewers everywhere is quite useful. And with JPEG XL becoming part of PDF, it will soon be common use cases too. As for the rest of the article: there are interesting points in the benchmark section but I think it's too early in the JPEG XL adoption cycle to draw conclusions. One thing bothers me though: There is a single picture comparison (with tag line "results speak for themselves") and I find it quite misleading: it's just picking one point on the "bytes received" line that looks best for AVIF compared to JPEG XL. Try it yourself and you'll see JPEG XL shows something already at 2KB while AVIF has nothing until 8KB, and JPEG XL looks better than AVIF after 100KB.
  • jaffathecake 20d ago
    For progressive, I think it's better to show the user something that's obviously a preview, but still has enough detail to be able to know what the picture is of. If you're showing the user something that they may mistake for complete but poor quality, that's a bad experience.
    • tzu321 20d ago
      That's a good point.
      • llm_nerd 19d ago
        It's an absolutely ridiculous point, and the guy you're responding to (who has commented almost 40 times in this discussion) has a hilariously slithery opinion that somehow always finds a way to hold every finding against JXL. Personally I don't like progressive rendering at all, but it's interesting that this same guy claimed elsewhere that it's super important on a very bad connection to get an early hint of what an image is. When someone points out that the "the results speak for itself" cherry picked example is absurdly misleading, and in most cases JXL is vastly superior at that case, instantly their opinion changes such that it shouldn't look like a poor quality image but it's somehow also a win that AVIF takes longer to give you anything at all to look at. Which is incredibly weird, given that AVIF also gives you a terrible quality image, it just takes longer to show it. So it sounds like they're completely against progressive rendering? Unless they think it gives AVIF a benefit? But it's an amazing demonstration of someone with an agenda. Utterly bizarre.
• Hendrikto 20d ago
  > This rules out JPEG XL's lossless advantage, which in practice is only roughly 11.9% smaller than lossless WebP anyway > It cannot be worth bringing a new image codec to browsers to save 12% What? 12% is huge.
  • jaffathecake 20d ago
    Yes but the decode time is orders of magnitude more.
    • PunchyHamster 20d ago
      who cares, you're not displaying 60 of them per second
      • jaffathecake 20d ago
        If the bandwidth saving gets you the image 10ms sooner, but due to the decoding time it takes 70ms longer to display, you're losing. And in the cached cache, the bandwidth saving is gone, and you're still paying the decoding penality.
        • spider-mario 19d ago
          Right, so in that hypothetical scenario where your bandwidth is over ~40MB/s, the bandwidth saving isn’t so relevant. That sounds a bit tautological?
          • jaffathecake 19d ago
            I'm not sure where you're getting those numbers from. But, in the cached case, the download time is very fast, yes.
            • spider-mario 19d ago
              And you might want the cache to either take up less space or hold more images.
• frizlab 20d ago
  > only roughly 11.9% smaller than lossless WebP anyway That’s huge, no?
• unilynx 20d ago
  Can whatever the next new image format for the web will be please have a JSON block at the start giving - dimensions - filetype - minimum required decoder version - lossless: true/false - a list of alternative URLs and mimetypes to older image formats And it doesn't have to be JSON, as long as it's in a fixed location (looking at you, AVIF and JPEG), extensible and can be decoded by just reading the first 8KB or 16KB. Then any future image format is a simple drop-in without requiring complex processing on the server side or a lot of complexity in HTML (not to mention CSS)
• shevy-java 20d ago
  I kind of settled on avif. I am not at all implying avif is perfect, in particular at high compression I notice the quality isn't quite as good as often advertised. For similar size compared to jpeg, avif is divine; and I also found avid better than webp in my own tests, so I switched to it. I don't quite see JPEG XL being really significantly better though. I think a really big problem here, even aside from Google trying to force deadlock people into its evil monopoly structure, is that we have competing formats (avif, jpeg-xl, webp) and that's IMO not so great when we want to have "one format to rule them all" that's better than jpg or png or gif. JPEG-XL is kind of a late starter here; if it is not really significantly better than avif or webp then I do not see it will gain any real foothold in the coming years.
• Lammy 20d ago
  Rather than AVIF or JPEG XL or WebP or HEIF or any of that stuff, my actual ideal choice that I wish everyone used is just good ol' JFIF. I like that I can take a file downloaded from the modern Web and open it on my '90s and 2000s computers. I emphatically do not care that it's some marginal percentage “““more efficient””” — more efficient for Google and Apple and Amazon and all the other silo providers who are moving more data every day than I will produce in my entire life. But why should I have to suffer backwards-incompatibility for their sake? Backwards compatibility is cool; stop the fucking churn! I have done this just within this past week, in fact, when I moved a JPG over to my Mac OS 7.6.1 machine (PowerBook 2400c!) to use as a new desktop wallpaper†. † Via Décor https://macintoshgarden.org/apps/decor https://macintoshgarden.org/apps/decor
• hirako2000 20d ago
  Lossless dismissed? 11% isn't nothing, that's trillions of images out there. Mozilla's own data shows JXL lossless beating AVIF and WebP. That's the one weakness of avif that bothers me, for lossy and speed it is brilliant. Companies may have another itch with the misleading licensing: AVIF's "royalty-free" is under active legal attack (Dolby v. Snapchat). JXL has clean ISO commitments so no such suit would be possible. If "free" matters, JXL is safer. Perceptive quality with the latest AV1 caught up, but that's a rigged timeline. Chrome supported JXL "late", then pulled it altogether. AVIF did improve further yes, it had web usage, it was behind when the race was meant to start. Why would JXL continue to optimize for web once the major browser refuses to support it.
• Semaphor 20d ago
  Is there a way to have fast on-the-fly WebP encoding? When i checked it, it was unusably slow (multiple seconds for large images), but maybe that was the implementation. That alone made JXL far more interesting to us.
• heaney-555 20d ago
  I would argue that as of 2026, we have enough storage and bandwidth that lossless compression is justifiable in almost every use case. Computers should not be making images look worse than they were captured. It's not 1996 anymore. We don't need to be doing this at all.
  • farlight 20d ago
    Depends on your location. While I have a decent internet connection at home, the mobile one is trash. Good for IM and not much else. Most of the people I know only have the mobile connection, pay a lot for the privilege, and while speeds are generally good (LTE and up), the monthly cap for almost all of them is 10-20 GB.
  • jaffathecake 20d ago
    Just to put some numbers to this, I looked at an image I recently took with my phone: Original image (JPEG): 3072×4080, 2.6 MB. Transcoded to JPEG XL: 2.1 MB. To display at 2x density on my web page, it would be 1598×2122. Lossless JPEG XL: 2.5 MB. Web-quality JPEG XL: 93 kB. Web-quality AVIF: 70 kB. It still seems worth it.
    • heaney-555 19d ago
      A 2.5 MB download just isn't a problem in 2026. I would far rather see the lossless image than save a few MB.
      • jaffathecake 19d ago
        If you're on a train, or a congested area, even 100 kB is a problem.
      • Liquid_Fire 19d ago
        Try traveling abroad with a prepaid data SIM (or limited roaming data allowance). Plenty of websites already have comically huge pointless images (often then scaled down to tiny sizes for display). No need to make the problem worse.
• blacklion 20d ago
  I think, whole idea of «web images» is silly now. Browsers are new OSes. There is no any «web» anymore. E-mail clients are web, news readers are web, image galleries are web, heck, even image editing software could be web (google:photopea). And as such there should not be «web-optimized» formats anymore.
  • jaffathecake 20d ago
    "Web optimised" really means "internet transfer optimised". Eg, the benefits would also be there for native apps that are downloading images from the internet, and they're not the web.
    • RunSet 19d ago
      In practice "web optimized" is a soft copyright control where the image is read-only to the extent the only readily available software that can open it is a web browser.
      • xigoi 19d ago
        All the formats we are talking about here (JXL, AVIF and WebP) have FOSS royalty-free encoders and decoders.
• PunchyHamster 20d ago
  Author entirely misses the case for what many people want it - re-compressing old JPEGs that they have no better sources for into JPEG XL with out decode-encode loss
  • jaffathecake 20d ago
    The author covers it: > JPEG recompression is the ability to losslessly re-encode JPEGs as JXL images while saving bits; the oft-cited number is 20% savings. However, the user pays for this in decode time, as recompressed JPEGs take ~33% longer to decode
• llm_nerd 19d ago
  These sorts of things always talk about progressive rendering. Who actually likes progressive decoding? Like...what year is it? I don't want an image to appear in any form until its loaded. I never need to see a blurry placeholder, and there is zero value in that even with bad connections, but the situation is farcical when everyone has ultra-fast connections everywhere. This is similar to pages that use custom fonts but will happily show the text as quickly as it can, and then suddenly restyle/relayout the page when the custom font loads (Flash of Unstyled Text - FOUT). It looks terrible and is jarring. Progressive rendered images are the same.
  • jaffathecake 19d ago
    I disagree with this. If I'm in a poor connectivity situation, a preview can help me quickly decide if an image is worth waiting for. I'm not talking about blurhash here - those are 'cute' at best. I'm talking about previews that let me determine the subject of an image. I was on a train recently and an image preview X delivered to me was enough for me to tell that the image was a particular meme format, and thanks to context, I knew enough about the image, and didn't bother waiting for it to load.
    • llm_nerd 19d ago
      You've left some 36 comments on this submission (which is honestly weird as HN usually rate limits to avoid that sort of aggressive participation), and your comments seem extremely...cherry picked. In another comment you dismissed the bandwidth savings of JXL because connections are so fast that eh, who cares, and in this case you herald the importance of progressive rendering because connections are so slow. Are you the author of the submission? Literally never seen someone so motivated in a conversation before.
      • jaffathecake 19d ago
        I dismissed the bandwidth savings in another comment because the increased decode time undid the benefit. I am not the author of the submission. I have experience in web performance, and my comments come from that experience.
• Pxtl 19d ago
  The form of JPEG-XL that can lossless convert to/from traditional JPEG is exciting tech that should be adopted universally. The non-backwards-compatible version of it seems redundant with AVIF.
• arthur-st 19d ago
  Strange blog post. Given that it's from a developer of proprietary and paid commercial encoders, the inclusion of their upcoming "aperture-alpha" encoder on the charts that are purportedly about JPEG XL makes this feel like a marketing piece of some fashion. Certainly, they advertise their Iris-WebP encoder throughout the post, with an implication that if you haven't paid to the author for it, you're not using WebP correctly, I guess? Moreover, there are some methodological oddities. For example, JPEG XL decoding is tested in single-threaded mode when it's optimized for multi-threaded decoding (where AVIF has artifacts from tiling). Also, the tested command is "jxl_cli --speedtest", which means that the benchmarked time includes the warm-up procedure of the "--speedtest" flag, rather than the pure decoding time. Another example of this is progressive rendering, where the comparison moment is chosen at a local maximum that favors AVIF. JPEG XL materializes a full frame much sooner than AVIF, and starting at, say, the 96,256 B mark, it looks better than AVIF until the full image is loaded.
  • deleted 19d ago
    [deleted]
  • Scaevolus 19d ago
    It also compares the total time for jxl-rs's benchmark mode (which does a warmup and a test decode) for 16-bit RGB against 8-bit WebP to 4:2:0 YUV.
  • computerbuster 19d ago
    I expected one of these bad-faith readings, so I can address that Aperture is mentioned once and Iris-WebP is only shown in numbers, because I have access to these encoders and thus they cannot be ignored. The only encoders I heavily advertise here are the incredible open-source AV1 encoders, that I contributed to for free and I think people should use. Also, not sure where you infer that point about WebP; libwebp is a fine encoder. AVIF does not have artifacts from tiling any more than JPEG XL has artifacts from being JPEG XL; if you read the details post at the bottom, you'd see there's a 0.5-1.0% BD-rate regression with tiles, which is effectively a rounding error. For progressive, JXL shows a blurry mess for the majority of its decode, while AVIF shows a crisp image that clearly shows what is in the image. Go ahead and try the demo yourself! AVIF also supports more than one layer, but I used Team JXL's image on purpose to show that even there, AVIF looks better for 90% of the decode time. You need to watch what I'm showing you instead of adopting the most bad-faith reading because some things are mentioned.
• bricss 19d ago
  No wukkas, JPEG XL support in Chrome ships by the EOM \o/
• mchusma 19d ago
  TIL that AVIF supports progressive decoding, cool!
• BugsJustFindMe 19d ago
  This blog post makes two incompatible arguments: 1) AVIF has now been radically improved to the point where it's actually quite good in ways that previously it was not. 2) JXL will not be improved despite the fact that the performance of every other codec has always radically improved over time. Everything else aside, including a few clear methodological errors, it's ahistorical and unsightly to be unwilling to imagine that future implementation effort will accomplish anything. Some might call it hypocritical.
  • juliobbv 19d ago
    I invite you to re-read the post carefully, with the attention it deserves. Hint: at no point the blog post says JXL will not be improved.
    • BugsJustFindMe 19d ago
      It sounds like you don't recognize the relationship between text and subtext. The entire post amounts to saying "JXL in its first iterations was better than AVIF's more advanced state of development and support, but AVIF very recently got better only after several years of widespread adoption, and I don't think JXL would too". The arguments given against JXL cannot be reconciled with the history of codec development.
      • juliobbv 19d ago
        Maybe you're just bad at reading text. Again, read the post carefully. Look around... nobody else had the same interpretation as you, so maybe that should clue you in something might be off with yours. The post literally goes over known ways that JXL can be improved. The actual argument (and this is stated!) is whether those improvements will be enough to make JXL compelling to use for the web vs. other established formats (quality efficiency, encode/decode time, progressive loading, etc). Also, don't assume AVIF or even WebP have maxxed out yet :) There are known ways to improve those two too!
        • 19d ago
• victorbvieira 19d ago
  [flagged]
• randyrand 19d ago
  JpegXL progressive decode is way better than AVIF: - it's first image is way earlier: 2KB vs 8KB - from 8KB to 100KB it's blurrier than AVIF, but it's more pleasing to look at and less blocky than AVIF. I highly prefer it. - from 100KB until finished 288KB it's actually ~4x sharper than AVIF Overall JpegXL gives the much nicer experience. ^ tested with pokebowl (https://jpegxl.info/resources/progressive-loading-demo.html https://jpegxl.info/resources/progressive-loading-demo.html)
• bigbuppo 19d ago
  I guess we found the tenth dentist.
• ksec 18d ago
  Had a lot of the content in this article came out 4 years ago I would have agreed. At least we finally don't have a fake Image Coding Comparisons [1] that tries to undermine JXL. Ignoring AOM and AV1, I was the first few on HN apart from its author supporting JXL from the start, I would argue the biggest case against JPEG XL is JPEG li. Jpegli offer enough quality improvement and advantage without introducing an entirely new codec. And all of a sudden the bar for next image codec now needs to be even higher. [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html
• 112233 18d ago
  "but strong mode-decision pipelines can pick the right mode for the job and save lots of bits" - citation needed. just a bit above author claims lossless is not useful for web, disregards modular jxl that uses nearby pixel predictors (even though it can be lossy, too), then produces this claim against vardct. spoiler - dct frequencies ARE using "nearby pixel values" really strange article.
• BlueSwordM 18d ago
  Hello everyone. Because of Gianni's great post, I've decided to go full throttle on rewriting and finally publishing the JXL vs AVIF post after deciding to partially shelve it last year. This should be especially interesting looking at the differences between my testing and Gianni's.