lobsters score: 4 · tags: compsci, web
Wow, I hadn’t realised how good lossy compression is nowadays. I’m struggling hard to tell the difference between the lossless and lossy even when switching rapidly between them.
score 1 · canonical
So the winners are clear. AVIF for deployed images, JPEG XL for source images.
AVIF is the new JPEG, JPEG XL is the new PNG. Funny outcome
score 1 · canonical
What I’ve found interesting is how bad lossless AVIF is. It’s so much bigger than WebP! Now, I know basically nothing about their internals so maybe there’s a good reason for this. I naïvely thought a newer format would be better, so it surprised me to see how much bigger the same images were.
This post also validates my choice of AVIF for my photo gallery’s thumbnails. :)
score 1 · canonical
Lossless WebP and lossless JPEG XL are basically different codecs compared to the lossy forms, which isn’t true of AVIF. That’s why JPEG XL at quality 99 can be larger than quality 100, because it mode-switches.
score 1 · canonical
I think you know this, Jake, but just to clarify for everyone here, while WebP lossy and lossless are basically completely separate things, JXL’s VarDCT mode (the lossy JPEG-like mode) heavily relies on its Modular mode (the FLIF/FUIF-like mode). The original JPEG has a lossless method of compression, which applies after the DCT step, but it really sucks. Really basic prediction for DC values based on previous DC values, run-length encoding, and of course Huffman. JXL also has to losslessly compress stuff after the DCT step, and since it has a high quality lossless codec built in, it of course uses it where-ever applicable. So it’s kinda like how Opus has two modes, but they’re heavily integrated and work together.
(If I recall correctly, AVIF’s lossless mode is basically like JPEG’s lossless step. Its primary purpose is to compress the data after lossy encoding, so while it was repurposed for lossless pixel compression, it doesn’t work well for that use case.)
And of course there’s the fun patches feature, where the encoder can notice repeating elements like font glyphs and encode them separately on a sprite sheet to be inserted into the main lossy image. Oh, and another bit of trivia is that the Modular mode supports lossy operation. Obviously there’s the classic trick of tweaking your pixel values to have lower prediction residuals, but Modular mode actually has (imagine a drum roll) wavelets! Sort of. It can do a Haar-like transform. Actually, often when used with lossy VarDCT, often some of the associated Modular mode frames will be encoded this way.
score 1 · canonical
On the screenshot example, the brightness of the white changes a lot between avif and lossless (especially noticeable on the underline for links). There is a similar effect on the shine in the woman’s glasses on the People picture. It might be something to do with the scaling algorithm (on 1080p, the image is shrinked quite a bit), but it doesn’t happen to the jxl images (which look exactly like the lossless ones to me). … aaand I just realized I’m on firefox 157, which doesn’t have native jxl support, so I’m just comparing scaling algorithms between a js-drawn canvas and real avif. After trying on 158, there is no such effect. It would be nice to get a link to open the full image in a new tab, to be able to compare the lossless to the lossy without being constrained by the website layout.
score 2 · canonical
(author here) Tell me a bit more about how the layout is constraining things. I want folks to look at the image as it would be presented, rather than zooming in, because zooming in is ‘cheating’. I could add a pop-out button, or a fullscreen button, but if the image size is still fixed, I’m not sure what it gains.
Edit: I tried the fullscreen option, and it’s kinda nice, especially for the large examples. Thanks for the suggestion. It’s there now.
score 1 · canonical
deleted by creator
It sounds like you’re looking in a browser that doesn’t support JPEG XL, so it’s falling back to wasm to display it, and it seems like canvas metrics are slightly different for some reason.
score 1 · canonical
Yeah. I was sure I had already updated to Firefox 158, but after double checking, I’m still on 157.
score 1 · canonical
It’s only cheating if you go over 100% and start pixel peeping. If I’m looking at a 2000px wide image shrinked by my browser to 700px, pretty much everything is going to seem indistinguishable from lossless. Ideally the images would be already resized for the intended display size. The fullscreen option helps, thanks!
score 1 · canonical
The images are already rezied to their intended size. The full screen option doesn’t change that.
score 1 · canonical
The people picture is 1598px wide, but it is displayed with
width: 799px(and in practice it’s 742.5px wide because of the container). I would expect an image reisized to its intended size to match the css width (I guess retina and high density screens throw this off, but then does that mean that we are serving 2x sized images to everybody to cater to the high density screen users?)
score 1 · canonical
Yes, that’s absolutely the intent, and it’s mentioned in the methodology in the article. I have another post on optimising for high density, and this is the technique I use on my blog.
score 1 · canonical