Have you tried Google's jpegli encoder? I find that it generally matches webp for most image types. Quantized png is usually best for anything with a limited color palette though.

WEBP/JXL is best for lossless, AVIF is best for lossy. But WEBP is more widely adopted (and also decompresses faster than JXL).

Webp is much better for lossless.

I have a similar tool at https://pictolab.io. I use it for tweaking the brightness and satuation of images mostly. For that you want HDR to reduce clipping, and most image formats have surprisingly bad HDR support besides AVIF (and jxl). Jpeg kinda supports it with gain maps but it's kind of tacked-on to the spec. Webp doesn't support HDR at all.

It's also surprisingly hard to support HDR input. For example, Apple uses a weird poorly documented format for the HEIC their iPhones take. I feel like HDR is just kind of a mess right now.

Lol I went through that same webp-vs-avif thing. AVIF supports HDR, so that's a good reason to switch.

> for screenshots though, and WebP works better for those

Interesting! Better in terms of more quality preserved or smaller file size? Have you found other types of images where this applies?

I thought it was pretty well established that JXL has a big room for improvement when it comes to encoders. There are some fundamental limitations wrt the absolute lowest bitrates, but that the room for improvement in encoders is rather substantial, especially with things like rate-distortion search heuristics.

The comparison is more about who has had the most man-hours and megadollars put into encoders quality than about the inherent limitations about the format.

With that said, I use AVIF, but I do have what can be said to be an irrational preference for JXL.

Jpeg-XL's key win was only lossless translation of existing jpeg to a modern format. Mostly for archives where you don't want a lossy translation.

In terms of picture quality for given size, AVIF has it solidly beat.

Agree, though I do miss the clarity of if an image is lossy or lossless just by extension. (Obviously a png could be produced from a heavily compressed jpg, but it is still a handy heuristic in my image pipelines)

12 seconds? It takes 7 seconds on my phone, in a wasm runtime using an older version of the encoder.

From my experience throwing random JPEGs at it, it's 3 to 4 times smaller, that's a good chunk of data saved, which in turn is a lot of energy saved on visitors' radios being active.

Unlike with jpeg, you don't need 85 or 95 percent on the quality score, 50 is more than good enough for most pictures on a website.

If you're hosting images and want a fully lossless encoding the CPU time may become a factor, but if you're hosting user generated content, I don't think it's all that bad. Plus, you can just move the encoding part to the user side of the equation and pretend it's part of the upload progress bar if you're desperate to pay the power bill.

This is also the reason JPEG2000 died off and became a niche format mainly for archival; it's extremely CPU-intensive.

You can adjust the speed of both, you don't have to use the default of whatever library versions you're using. My cjxl defaults to 2x more CPU than avifenc's default, but I can make it 30x more or 480x less; libaom certainly lets you waste a lot more CPU than libjxl, if that's what you want.

I don't know if anyone has published an encode time / quality comparison of the various encoders. It'd have to be recent to include this year's libaom image optimizations.

> replaces JPEGs on the front-end of WordPress for browsers that support them.

Ouch. Pretty much every browser supports AVIF now which means everyone gets transcoded images worse than JPEGs one uploaded. For JPEG XL that process is lossless...

Probably not. But if anyone ever decides to enforce patents over AV1 or AVIF, they will fight about every company in Big Tech and quite a bit of Hollywood: https://aomedia.org/about/members/

Yes. It’s just an AV1 container. Doesn’t even need to be limited to a single frame (just like GIF and APNG).

Hard to say, but possibly less since it's a still image, not a video, so it inherently corresponds only to a part of AV1.

No need to worry about these risks for using it though. You can never say that no patent troll will surface tomorrow for literally anything. That's not a reason not to use things.

It's pretty frustrating that JPEG encoding generally got stuck with libjpeg-turbo.

I keep seeing people saying that nothing supports webp, but I've never had any issues opening it. What software do you use that cannot handle webp?

You can throw almost any image format with open standards into squoosh.app if you're still using software that doesn't open webp.

It's been a while since Photoshop finally got support, though, I can't recall the last time webp posed a problem for me. Then again I don't use a Firestick, no idea how that would deal with image formats, I guess it's no longer being maintained?

AV1 (and AV2) do save a lot of bandwidth, and Youtube already serves AV1 selectively to some users. But the biggest drawback of AV1 is that it needs more resources to even decode. This is especially apparent on old computers that don't have dedicated AV1 encoders or decoders. I discovered this when someone complained to me that PaleMoon on their old PC suddenly consumed a lot of CPU resource causing the PC to stutter - turned out that Youtube was serving AV1 encoded videos on it. Disabling AV1 support in the browser fixed it as Youtube was then forced to serve AVC / H.264 encoded videos.

not an odd argument. AVIF is based on AV1, so what they mean is that since we accept YouTube's AV1 usage as mainstream nowadays, so should be it's image part

Say more please, what’s up with keyframes?

> Enough keyframe-based "image" formats, please! The internet and the world at large needs a real and proper modern forma

Are you looking for jpeg XL?

> and do not leverage any existing infrastructure for serving video

How would that leveraging work?

> WebP, AVIF are the webscale equivalent of serving images.

This sounds insulting? But they are images on the Web. I have no idea what you mean here.