| ▲ | computerbuster 9 hours ago |
| I'm the author if anyone has questions – AMA |
|
| ▲ | aidenn0 6 hours ago | parent | next [-] |
| 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 2 hours ago | parent [-] | | Have you tried the latest AVIF encoder? It's quality setting seems much more stable. |
|
|
| ▲ | adzm 9 hours ago | parent | prev | next [-] |
| 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 9 hours ago | parent [-] | | Lossless was discounted because lossless just isn't very useful on the Web | | |
| ▲ | SmasherEpilepti 5 hours ago | parent | next [-] | | 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 5 hours ago | parent [-] | | 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 an hour ago | parent [-] | | 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. | | |
|
| |
| ▲ | slimbuck 4 hours ago | parent | prev | next [-] | | 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-splatt...). Scenes often comprise gigabytes of lossless webp, some of which you can see at https://superspl.at. | | |
| ▲ | slimbuck 3 hours ago | parent [-] | | 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! |
| |
| ▲ | F3nd0 7 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | dylan604 9 hours ago | parent | prev [-] | | 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. |
|
|
|
| ▲ | a-french-anon 3 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | pkulak 9 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | gsnedders 3 hours ago | parent | next [-] | | 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.) | |
| ▲ | computerbuster 9 hours ago | parent | prev | next [-] | | AVIF is royalty-free, & SVT-AV1 and libaom are open source. Edit: saw you corrected. Much appreciated! | | |
| ▲ | dannyw 9 hours ago | parent [-] | | 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 9 hours ago | parent [-] | | 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. |
|
| |
| ▲ | abhinavk 9 hours ago | parent | prev [-] | | Both are open I think. |
|
|
| ▲ | vasilvv 3 hours ago | parent | prev | next [-] |
| 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? |
|
| ▲ | vlmutolo 9 hours ago | parent | prev | next [-] |
| What do you think the best use cases for jxl are? Where does it still have an advantage over other formats? |
| |
| ▲ | computerbuster 9 hours ago | parent [-] | | 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 5 hours ago | parent [-] | | 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. |
|
|
|
| ▲ | wmf 8 hours ago | parent | prev | next [-] |
| 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 6 hours ago | parent [-] | | 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. | | |
| ▲ | a-french-anon 3 hours ago | parent | next [-] | | Wait... SVT-AV1 doesn't support anything else than 4:2:0, right? Kinda biases the comparison here. | |
| ▲ | KingMob 5 hours ago | parent | prev [-] | | > 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! |
|
|
|
| ▲ | rmunn 9 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | alwillis 8 hours ago | parent | next [-] | | > 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. Both Firefox and Chrome [1] have committed to shipping JPEG XL later this year. Safari has supported JPEG XL since 2023, though their implementation doesn't support progressive images yet. So the major web browsers will support JPEG XL later this fall. [1]: "Intent to Ship: JPEG XL" - https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ | | |
| ▲ | account42 an hour ago | parent [-] | | > though their implementation doesn't support progressive images yet It doesn't support progressive images or it doesn't support progressive decoding of images? The former would be a massive compatibility issue, the latter would only be a quality of implementation issue. | | |
| ▲ | jaffathecake 43 minutes ago | parent [-] | | In terms of AVIF, only Chrome supports progressive decoding. In terms of JPEG XL, Firefox and Chrome support progressive decoding, Safari does not. In all cases, the browsers are able to render the final image, they just don't show the intermediate stages. |
|
| |
| ▲ | computerbuster 9 hours ago | parent | prev [-] | | > 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? | | |
| ▲ | rmunn 8 hours ago | parent [-] | | HDR is something many photography enthusiasts are interested in, and the ability to losslessly transcode from JPEG to JPEG XL (and back again if you have to) is actually IMHO the "killer app" for the format. Many people have years of irreplaceable family photos in JPEG format, and being told "you can fit 30% more photos on the same hard disk without any loss of quality" would certainly sell me on converting my photo library to JPEG XL. (The jpegxl.com site says "up to 60% smaller" so I'm going to guess that 30% is a safe average gain and it might be more). And nearly everyone who takes photos of their family ends storage-constrained on cameras at some point. Memory cards only holding so much is less of an issue than it used to be, but in my experience the only people with laptops that have more than 1 TB of disk space are the computer professionals I know; every non-computer professional I personally know has 1 TB or less, usually 512 GB. That's room for plenty of photos, but not an infinite amount, and the photo collection (plus videos of baby's first steps and so on) is competing with a lot of other things for storage space. So being able to shrink the collection size by 30% or more with no artifacting added is definitely going to be worth it for one of the biggest selling points for cameras. (Including the cameras on smartphones). I wouldn't say that JXL is absolutely vital and the industry should switch right now. But I would say that it's likely to be the only image format that has a chance to displace JPEG among the average camera user. Having JPEG in the name is also going to be a major selling point; don't underestimate that. (And the JPEG <-> JPEG XL conversion being lossless will complete the selling point). Since (if I'm right) it's going to end up ubiquitous, then even if another format would be technically better, it would be wise for everyone writing software that handles images — browsers, OS file explorers, and so on — to make sure their software can support it. Just on general principles of supporting every widely-used format and every format that looks likely to be widely-used in the future. |
|
|
|
| ▲ | xigoi 2 hours ago | parent | prev | next [-] |
| What format would you recommend for archiving photos if I don’t mind slight quality loss? |
|
| ▲ | rodarmor 4 hours ago | parent | prev | next [-] |
| Very compelling and thoughtfully written article. Thank you! |
|
| ▲ | kinesin 6 hours ago | parent | prev [-] |
| 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 5 hours ago | parent [-] | | 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 |
|