@sundew There's a coding tool called Patches that allows you to basically copy a pattern to several places in an image - it is used for things like letters in text or repeated icons etc. But the residual error is still encoded, there is no 'fuzzy matching' being done like in some lossy jbig2 encoders where the near-match is the only thing that gets encoded, there is always a residual image too.

@sundew Not with the libjxl encoder. But for any format you can in principle make a bad lossy encoder that makes bad choices...

@oblomov There are also Thorium, Pale Moon, Basilisk, Waterfox, and the Chromium shipped in OpenMandriva.

@kkarhan @fsf Besides the unfortunate ISO paywall for the official spec, there is nothing non-open about JPEG XL. It is royalty-free and the reference software is BSD licensed. There are 3 independent implementations that are all also FOSS. It is just as open a standard as, say, C++ or Unicode.

@RL_Dane @gianni Encoding can be more complicated than decoding (if you want to do perceptual modeling and compress well), or it can be simpler than decoding (if you just do something simple). Slow software encoding will produce better results than fast software encoding or hardware encoding. This is why I don't believe hardware will help much to make avif encode faster: sure hw avif encode will be fast, but it will compress worse than software jpeg encode, so I don't really see the point...

@gianni @RL_Dane Yes, that's correct. Apple devices also do the encoding in independent tiles of 512x512 pixels, probably to keep the hardware footprint smaller. This is not so great because it leads to visible seams at the tile boundaries (though this is a relatively subtle artifact at high qualities).