[t-writescode]

I encourage everyone to click the images and zoom in on them. The test itself is pretty flawed since the images probably all came from the jpeg in the first place (and if they didn't, then that's pretty damning to the non-jpeg options, in my opinion).

The place I found the most interesting is the dark, top of the screen. Zoomed to 240% and looking at the top area, especially where the power lines are going across, there's a very, very clear difference in quality between even the 95% jpeg and webp, and in my opinion, the jpeg wins for being more honest. That difference is more stark at the 65% compression option.

Is that difference worth the larger size? That's up for each of us to decide as we choose our technology; but, those images are very different from my perception.

Caveat: I've used Firefox to render them, which may have different results than Chrome, perhaps.

[jug]

> Zoomed to 240% and looking at the top area

This isn't what any lossy formats are designed for.

How much do the lossy spots stick out when viewed in a cursory glance without zooming from a normal viewing distance? This is what lossy formats are designed for.

[lifthrasiir]

If that's indeed true, there is no point to compress an image that is larger than a target viewport---any larger image can be scaled down on encoding and upscaled on decoding. But all formats mentioned easily support much larger images.

[jug]

When I said "This isn't what any lossy formats are designed for", I meant on the web, which I thought was the context with the article and all. And then there is indeed little point of uploading images to a web server that is far larger than viewports.

I also still maintain that lossy formats aren't designed to manage users zooming into textures and trying to find out compression artifacts and wavelet caused softening of power lines. We have lossless compression for this and in this regard, WebP is actually surprisingly powerful, far far more so than PNG.

[lifthrasiir]

In case you didn't realize, "designed" is a very strong word. JPEG was certainly not designed for the web; the first web browsers didn't support inline images. WebP, despite of its name, is a key frame from VP8 which wasn't not exactly designed for the web; it was the latest iteration of TrueMotion codecs developed by On2 Technologies before its acquisition to Google, and while later codecs were also used in the web, they initially targeted games and later expanded to the general purpose format. AV1 and AVIF is probably the only format that can be possibly designed for the web due to their explicit goals.

And even so, it is utterly unclear to me how lossy image formats can be designed "for the web" in the way you have described. I will probably expect a good progressive decoding support and possibly animation, but that's all. Otherwise it's a good old psychovisual optimization under specific viewing conditions, and it is much debatable which viewing conditions represent the web environment.

> I also still maintain that lossy formats aren't designed to manage users zooming into textures and trying to find out compression artifacts and wavelet caused softening of power lines.

Which is a fair point but WebP at the lower quality does show significant enough artifacts visible without zoom for ordinary displays. Mobiles with higher pixel density in a constrainted form factor do matter, but you can't ignore ordinary displays in your file format solely for that reason.

[lifthrasiir]

Yeah, WebP was long criticized for its loop filter for example, which was a good fit for videos but not much for still images. In comparison, JPEG compression artifacts are so well understood that better encoders that minimize visual artifacts are available. I'm not even sure whether there is an original uncompressed image---that JPEG file might even directly come from a camera.

[crabbone]

Well, there are many things at play here... JPEG leaves it to the codec author to interpret the compressed information. You can get different JPEG implementations that will result in visually different images (on screen) when displaying the same file. Some JPEG viewers will even allow you to control some of the parameters of the render (typically, the amount of blur and the size of the "swatch" with which the blur is applied).

This is less noticeable with stills, but it's a special form of art / a matter of professional pride for teams working on video codecs: how to make pictures produced from the same file look "better".

Similarly for compression. It's far from given that two different JPEG implementations will create byte-for-byte identical files given raw image input and all the same compression settings. There's special art in figuring out what parts of the picture will compress better, what parts can use wider "swatches" etc.

It's also true that different codecs can perform better on different kinds of pictures either in the sense of producing smaller files or in the sense of producing more visually appealing picture. So, anyone trying to establish the behavior of compression of competing codecs needs to try this on a carefully selected set of images which need to include images with high and low brightness, sharp and blurred images, pastel colors and neon glow as well as pictures of things we are often interested in seeing s.a. portraits or medical images etc.

There won't be usually an all-winning codec.

Also, as for the images compared in OP: does OP know if there's any metadata written into those images? I mean, the answer can be as simple as discovering that JPEG images included a thumbnail in the image, and then all that measuring would be worthless...

[303uru]

Why? Isn't this the entire point. 99.99999% of vistors to my website never click on a photo and zoom to 240%. Why serve all that extra data so that once in a lifetime pixel peeping weirdo doesn't get upset? If you're running a photography portfolio or something akin to it, then sure, serve big images. But for most of the web there's no reason to.

[jareklupinski]

> 99.99999% of vistors to my website never click on a photo and zoom to 240%. Why serve all that extra data so that once in a lifetime pixel peeping weirdo doesn't get upset?

because, statistically, at some point every one of us will be the 0.00001% in someone else's problem... wouldn't you rather that they tried a little harder for you too? ;)

[303uru]

Honestly, no. It's a waste of energy, bandwidth and storage space.

[jareklupinski]

> It's a waste of energy, bandwidth and storage space.

yet for some reason, we keep on going shrug

[xuhu]

And the blue shirt in the lower left corner. In webp-65% all the texture detail from the other versions is lost.