Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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)
by randyrand - 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.
by Dwedit - Lossy Modular isn't efficient enough to compete with even JPEG.
Also, look at the graphs – Iris-WebP beats JPEG XL.
- 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).
by IvanK_net - 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.
- This comment reads like you summarized the post and didn’t read it
- 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.by juliobbv
- 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.
- 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.by doodlesdev
- > 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/36000262921...) and I don't expect support to ever be added since it is not formats intended for photography.
by meinersbur - 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".
by Pikamander2 - 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.by jaffathecake
- I got an impression JPEG XL is not a single format, but many formats put under one brand (same as webp), you still need to choose these formats and transcode between them.by GoblinSlayer
- 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.
by nneonneo - I wonder if similar hacks apply to zlib and .png as well.by est
- The primary problem with that image is that is has over 60 channels, which means it'll take 20x more time to decode no matter what. Incidentally, the JXL spec suggests that web browsers shouldnt't decode images with so many layers. Jxl-rs will probably start enforcing such limits by default.by lonjil
- When a format has so much flexibility, the world will glom onto the first thing that it solves and put it into the wild to solve that problem. The rest of the capabilities fall by the way side, yet not removed from the format. They're just ignored. MP4 can do so much more than the typical deliverable of a video stream and an audio stream. The spec allows for multiple video streams, multiple audio streams, subtitles, Flash like interactivity to allow self contained DVD style programming of menus to allow for chapter navigation, audio/sub selection, multiangle, etc.by dylan604
- 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.
by F3nd0 - "We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds".
You'd rip a new one to Google if there would be a CVE in a new C++ library in Chrome because of it.
Now that Rust library is available, they will continue adoption, as it should be.
by izacus - > It won’t be know until it’s been tried
We can reevaluate when and if improvements are made. The problem with statements like this, is its really easy to miss the showstoppers when imagining what something could be. All plans are amazing until you have to actually do them in the real world.
As the saying goes: Never fall in love with potential.
by bawolff - 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.
- "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.
by Feathercrown - In the context of the world it's all hair splitting, you can have a big photographic picture in png, or 1% compressed jpeg, or 1% jpeg converted to png. No new format can change it.by GoblinSlayer
- "These should just be vector images instead" is an argument made by someone who has never in their life attempted to create a vector image.by dada78641
- 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.
by karim79 - 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.
by Daiz - AVIF's support for non-photographic images is covered in the article. It supports lossless.by MrSqueezles
- I don’t think hardware decoders are used for images. They are light enough you can do it in software.by Gigachad
- Wait, DAIZ!? I genuinely did not expect to see you here chiming in. Still appreciate much of your 10 bit anime advocacy from way back.
- In the modern age image decoders need to handle untrusted inputs, and the big players rarely use hardware image decoding, even when it's available, because it's so hard to rely on its memory safety.
Several 'zero click exploits' have involved image/document format decoder bugs, as messaging apps and file browsers will often generate preview images the moment an image arrives.
by michaelt