computerbuster

Why does that bias the comparison exactly?

Will do going forward, thanks for the feedback!

Well-put.

Luckily, 4:4:4 AVIF is supported in Firefox, Chrome, and Safari, right now. This won't ever regress.

I was even more surprised & disappointed to see this dismissed as an ad for my company. Think about how fantastic JPEG XL would be for my company: an image codec with tons of fans and an extremely weak reference encoder? Sign me up. I'm writing this as someone who wants a better Internet.

If you're sensitive to tiling artifacts, you must deeply dislike the way JPEG XL images look. Every block of a JPEG XL image is effectively a small tile, because there is no deblocking loop filter (I talk about this in the article).

JPEG XL has two filters that are pretty much equivalents of what AVIF has, while AVIF has three; plus, tile boundaries are handled by the DLF. Your point doesn't really stand on two legs if it means to come to JPEG XL's defense here.

JPEG XL isn’t consistently better enough to justify it. If lossless is so important, maybe we should be campaigning for HALIC.

This comment reads like you summarized the post and didn’t read it

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.

I’ll just repeat another comment here:

“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.”

-jaffathecafe

There have been a number of experiments to use hardware decoders for images in browsers, all of which have fallen flat; not even Safari does it for AVIF or WebP. Thus, 4:4:4 AVIF is supported absolutely everywhere. Feel free to try it now. I can see how hwdec is compelling for JPEG XL in theory, given how slow decoding is.

I think libjxl's development is stalled because the format is hard to work with. It wasn't super hard to drive meaningful improvements to AVIF.

Yes, SVT-AV1 received and continues to receive development efforts from devs at big companies, but the number of core contributors has always been somewhat small. Definitely more resources, but the entirety of the original AVIF work was done by two people.

I'm able to utilize my experiences generally in image coding to work on my encoders. This should translate to JPEG XL, but I feel held back by how algorithmically complex compelling implementations of the coding tools would be, and how to make those implementations fast. I think if the JPEG XL spec was incredibly intuitive, community contributions would have gotten it a lot further. Heck, my own efforts may have gone to it instead of SVT-AV1-PSY's AVIF encoding.

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.

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.

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.

Looking forward to a future where we can arbitrarily DoS anyone with a PDF that computes massive swaths of prime numbers.

Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.

Lossy Modular isn't efficient enough to compete with even JPEG.

Also, look at the graphs – Iris-WebP beats JPEG XL.

I believe wholeheartedly that AVIF's approach is significantly better UX.

> 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?

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.

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.

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.

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.

Think about how many images large platforms deliver every day, and the benefits of saving bits on each of them.

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?

AVIF is royalty-free, & SVT-AV1 and libaom are open source.

Edit: saw you corrected. Much appreciated!

Lossless was discounted because lossless just isn't very useful on the Web

I'm the author if anyone has questions – AMA

blog: https://halide.cx/blog/fmetrics/

I think these conversations are directed by the parties funding the efforts. Example: "we (large company) want a fast AV2 decoder" -> they pay a specialized team to do it -> this team works in C for the most part, so it is done in C. If there were financial incentives to do it in Rust, they'd pay more for a Rust decoder.