Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebP is so great except it's not (2021)

eng.aurelienpierre.com

Post reply on HN
Print view View original

361–370 of 411 posts

Re: WebP is so great except it's not (2021)

#361

Post by [deleted] »

_fat_santa wrote: post #216
V__ wrote: post #4

I opened the first two pictures in separate tabs and switched quickly between them. There is zero difference. Tried it on two different monitors, Chrome and Firefox. Same with the pictures of the guy at the end. EDIT: The last comparison is webp twice, he linked it wrong. Here is the jpg one, still no difference: https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

Lots of replies here saying either: "I can't see the difference" or "Wow the difference is stark". My takeaway as a non-photographer is: "different tools for different uses". If you're posting photography where image quality matters then use JPEG or another format that you think displays the image best. If you're writing a blog post with screenshots or other images where minute quality doesn't matter that much then u…

[deleted]

Re: WebP is so great except it's not (2021)

#362

Post by gruturo »

karmakaze wrote: post #306
Findecanor wrote: post #262

Earlier quoted context omitted.

> Re-encoding from a lossy compressed source will make quality worse. JPEG-XL is supposed to reencode old JPEG files into 20% smaller files without quality loss though. In context, Google has been holding JPEG-XL back by removing support for it from Chrome and refusing to reinstate it, claiming that it did not have good enough "incremental benefits compared to existing formats" such as webp.

Wow, I didn't know that. A top google result says: > It is possible to losslessly transcode JPEG images into JPEG XL. Transcoding preserves the already-lossy compression data from the original JPEG image without any quality loss caused by re-encoding, while making the file size smaller than the original. I wonder how it does that and why JPEG didn't notice it could. I would re-encode to JPEG-XL, when supported. So th…

> I wonder how it does that

It's trivial to do: JPEG's last stage is a compression via Huffmann code - which is a really ancient, not particularly effective compressor. You simply decompress that stage, and compress with something more modern, yielding better savings. Stuffit did it in 2005. PackJPG in 2006. Brunsli (a Google project!) in 2019 - and it was one of the inputs to the JXL draft. Lepton did it in 2016.

> and why JPEG didn't notice it could.

Oh that's the best part - they did, all the way back in 1991. The JPEG standard allows you to choose for the last stage between Huffmann and Arithmetic Coding - which is way more effective. Unfortunately it was patent-encumbered and its support is low. It yielded 10%ish space saving which wasn't worth the compatibility headache (it has the same extension and mime-type of a Huffmann-encoded JPEG, so a webserver won't know if your browser supports it). If it only had used a different file extension it would probably be the dominant format today.

Re: WebP is so great except it's not (2021)

#363

Post by sexy_seedbox »

mihaic wrote: post #30

This article didn't go into the biggest problem with webp for me: the inconveninence of the format outside the browser compared to the small space saving. There are better formats (the video-codec inspired ones like heif, avif, and what might come out of h266, or even jpeg-xl), and webp just seems like a compromise without enough upside.

Now let's talk about HEIF, an inconvenience inside and outside of the browser on desktop.

Re: WebP is so great except it's not (2021)

#364

Post by virtualritz »

doctorpangloss wrote: post #350
vardump wrote: post #20

Earlier quoted context omitted.

I checked those images on a Macbook 16 M2 Max (standard P3-1600 nits preset), Chrome 120.0.6099.109. All of the WebP images had pretty bad posterization, while JPEG examples did not. Edit: You have to actually click for a full size image to see the truth. Those inline images had pretty bad compression artefacts, even the supposed lossless versions. So https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (f…

> I wonder if there's some issue with the WebP encoder (or the settings) he is using? He's re-encoding the JPEG compressed images. That is a huge mistake.

From the article:

> It’s not 100 % clean either, but much better. Granted, this is WebP re-encoding of an already lossy compressed JPEG, so we stack 2 steps of destructive compression. But this is what Google Page Speed insights encourage you to do and what a shitload of plugins enable you to do, while pretending it’s completely safe. It’s not.

Re: WebP is so great except it's not (2021)

#365

Post by virtualritz »

BackBlast wrote: post #256
ubercow13 wrote: post #122

Earlier quoted context omitted.

The authors point is that if you are making this tech, you should have educated eyes. And given all the confident comments in this thread claiming the author is full of shit and there's no difference, I think their frustration is justified? If you can't see the difference in the first images that's fine but you probably shouldn't be confidently claiming to know better than the author, let alone designing an image cod…

There's room for different opinions. His font choice is terrible for my legibility. Maybe for others it's great. But it made the already difficult article that much harder to read. And I like this topic. I already seriously question his sense of what is reasonable and good and for what purpose. His purposes are so alien to mine that his opinion ends up being pretty irrelevant to mine. I wish him well with his. I can'…

> His font choice is terrible for my legibility.

There may be a connection [1].

If we assume some of the people designing codecs, that he curses in this piece, end up reading it, he may simply have wanted to make sure they do remember. ;)

[1] https://hbr.org/2012/03/hard-to-read-fonts-promote-better-re...

Re: WebP is so great except it's not (2021)

#366

Post by mceachen »

Findecanor wrote: post #262
karmakaze wrote: post #188

If I cared about archive image quality (and I do) , I wouldn't re-compress older images in a new format unless I could do so from uncompressed originals. Re-encoding from a lossy compressed source will make quality worse. Storage is cheap and getting cheaper. What would make sense is choosing safe settings for compressing new photos in the new format.

> Re-encoding from a lossy compressed source will make quality worse. JPEG-XL is supposed to reencode old JPEG files into 20% smaller files without quality loss though. In context, Google has been holding JPEG-XL back by removing support for it from Chrome and refusing to reinstate it, claiming that it did not have good enough "incremental benefits compared to existing formats" such as webp.

Careful with the JPEG-XL re-compression, though--depending on how you're re-encoding, jxl may use SSIM to evaluate for visual losslessness, and the whole point of TFA is that SSIM is blind to posterization, but (some) humans aren't.

Disk space is cheap. It's most likely not worth the 20% compression to lose your original images (and possibly lose metadata as well--it's quite hard to robustly retain all vendor-specific MakerNotes, for example).

Re: WebP is so great except it's not (2021)

#367

Post by x0x0 »

ubercow13 wrote: post #122
627467 wrote: post #66

> To the non-educated eye, this might look ok, but for a photographer it’s not, and for several reasons. There surely must be better examples to show "non-educated" plebs (to use the tone of the post) why webp is bad and to justify the post and the tone. I'm on Android, maybe this is why all pic quality look the same? Also - yeah, if you are making pics for educated eyes: don't use tech that is not suitable for educa…

The authors point is that if you are making this tech, you should have educated eyes. And given all the confident comments in this thread claiming the author is full of shit and there's no difference, I think their frustration is justified? If you can't see the difference in the first images that's fine but you probably shouldn't be confidently claiming to know better than the author, let alone designing an image cod…

The author's point is deeply stupid. As he admits:

> WebP re-encoding of an already lossy compressed JPEG

So... all this shows nothing. Is webp worse than jpeg? Not addressed. He re-encoded jpeg to webp and it somehow didn't magically cure the compression artifacts he's seeing! Who coulda thunk!

Any comparison starts with taking the originals, encoding to jpeg and webp, and comparing that. Or he could repeatedly encode original -> jpeg -> jpeg and compare that to what he has, which is original -> jpeg -> webp

Re: WebP is so great except it's not (2021)

#368

Post by AlienRobot »

imo, the problem isn't that WebP is bad for photos.

The problem is that Google's Pagespeed Insights and consequently a lot of resources push WebP to you as a solution for your JPG problems.

A lot of people have been duped into reencoding their JPEGs into WebPs for no reason.

Also just my personal feelings, but I feel like Google doesn't care about people downloading images or using the internet as a permanent gallery for posterity. They don't care about making each individual image look as good as it can be, so someone can in 10 years visit an almost-defunct website or an abandoned account of some user and just view a photograph as a standalone work. It feels like the use-case they're concerned with are the huge 1200px wide, utterly useless and generally irrelevant stock images they forced everyone to put on their articles when they said AMP articles require an image that big. And of course, with the thumbnails automatically generated from such images. That is, WebP's concern seems to be just about the load on the web server, and it's not thinking about the image as a file (the sort you save on your computer). Then again, this is just my strongly opinionated guess based on nothing but the fact JPG was made before the web became what it is today, and WebP was released after mobile internet access surpassed desktop.

Re: WebP is so great except it's not (2021)

#369

Post by AlienRobot »

rambambram wrote: post #147

I might be missing something because I never delved into it, but my problem with WebP is I can't save images this way from my browser. Well, I can save them, but they don't show up when I try to view them on my system (Ubuntu Mate 20.04 on RPi4).

They don't show up on older Windows versions either. The file explorer needs some sort of library to handle .webp thumbnails correctly. I'm pretty sure you can install something on Ubuntu to make them show. Maybe try a different file manager?

Re: WebP is so great except it's not (2021)

#370

Post by siddheshgunjal »

Author might be right about the gradient shifts in images after conversion, but at the same time, most of the websites are not using such color accurate images everywhere. Some are logos and some are with alpha channel. It is a fact that WebPs are lightweight assets to load on the user side which reduces bandwidth consumption for the user and your server. So use WebP where it's needed to save some loading time and bandwidth and use your preferred format where you want to show images as is.

If you're planning to convert your images to WebP in bulk, I wrote a shell script: here's the link:

https://medium.com/@siddheshgunjal82/bulk-convert-images-to-...

Post reply on HN