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

171–180 of 411 posts

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

#171

Post by 2OEH8eoCRo0 »

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...

It's your screen. Maybe we found the ultimate image compression method here- we all just need to use the same screen as you.

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

#172

Post by arghwhat »

chrismorgan wrote: post #60
Latty wrote: post #7

Earlier quoted context omitted.

I must admit, I'm not sure why JPEG XL is viewed so favourably on HN, it's not something I know a ton about, but my understanding is that the big advantage of AVIF is that you can reuse hardware decoders built into devices for AV1 for the images. It being a strict improvement over JPEG is nice for the developers not having to go back to the source image for an upgrade, but that seems like a pretty small benefit that…

AVIF kinda needs hardware decoding, because otherwise it’s considerably more expensive than the traditional codecs. Even with hardware decoding, I’m not sure if AVIF is actually faster/chaper—compared in https://jpegxl.io/articles/faq/#%E2%8F%A9speedfeatures , “AVIF” takes 7× as long as libjpeg-turbo to decode, and I don’t believe hardware en coders tend to bring that big a performance difference over software, but I…

> AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff.

Mobile devices on battery are connected wirelessly, so traffic consumes a lot of power. The faster the radio can power back down the better, so CPU time is usually a worthwhile trade.

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

#173

Post by Pxtl »

bawolff wrote: post #11

I dont get it. The author seems to care highly about image quality, but also wants to squeeze out as many bytes as possible? Bandwidth is cheap. If we are talking about photography as art, why would you be trying to scrap a few kb off in the first place?

Because it's a substantial amount of effort to upgrade to the "new" tech, and he's showing that the "new" tech is actually worse than the "old" tech of reliable old jpeg.

> Bandwidth is cheap.

Labour is not. Just leave your jpegs as-is!

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

#174

Post by markdog12 »

ColonelPhantom wrote: post #3

It's such a shame Google decided to block adoption of JPEG XL: it's a strict improvement over classic JPEG (you can losslessly reencode JPEG to JXL and reduce the size, due to a better entropy coder in JXL!) and JXL has various other upgrades compared to 'classic' JPEG. In the meantime, let's hope AVIF or whatever manages to pick up the slack, and/or other browsers decide en masse to support JPEG XL anyway; that woul…

Seems Safari has it enabled by default now, and Apple has support at the OS level. Firefox at least has it under a flag. Chrome team are the odd ones out here.

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

#175

Post by acdha »

2OEH8eoCRo0 wrote: post #164
layer8 wrote: post #157

The simple truth is that JPEG is more than good enough and has ubiquitous support. There is no reason to switch to a different format and risk degradation or reduced interoperability for slightly smaller file sizes.

I don't understand fanatically chasing smaller image sizes when JPEG was good enough for the web of the 90's. There must be a different reason to throw some of the highest paid engineers in the world at WebP and it ain't generosity.

Google spent a large amount of money purchasing On2. WebP and WebM were a way to show shareholders that they were seeing benefits from the acquisition, and if you look at Google’s traffic volume you could make an argument that even a modest size reduction would pay for the engineering time.

The problem was that this was basically only true for the largest sites. If you’re YouTube or Netflix, it pays to optimize your video encoding but for most other sites the volume just isn’t there and the performance costs for anyone who uses a CDN cancel it out because you need a lot of traffic for each format before a 10-20% byte size reduction saves more time than the cache misses take.

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

#176

Post by rchaud »

Outside of photographers, how many people are looking at super high-resolution images on the web? Even images that might have high-resolution versions are usually converted to a shrunken image 600px wide to fit inside the website's theme scaffolding.

Is that really even worth shaving 15% off the file size? If bandwidth matters, websites should look to reduce the volume of useless stock images littering their templates.

WebP seems like a gift to Cloudflare and the other companies that do the heavy lifting of caching and serving millions of images across multiple sites. For users, it's at best indistinguishable from JPEG, and at worst an obstruction to saving images from the web.

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

#177

Post by Pxtl »

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).

In general I've found that this shift to .webp breaks all the nice interoperability and composability we used to have with audio and video image files since there seems to be zero interest in making sure that simple familiar features like still work.

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

#178

Post by acdha »

pembrook wrote: post #124

I've noticed the same issue with WebP and have gone back to JPG/PNG for most things (jpg for photos, png for UI-type images) I think the real problem is, like many of the commenters here, most people can't tell the difference because desktop monitors have been stuck in a deadzone of zero innovation for the last 10 years. I'm sure half the folks here are viewing his example images on a 2012-era HD 1920x1080 LCD, which…

It’s quite noticeable on a 2011 MacBook Air, too. The issue is less pronounced if you don’t have a decent display but it’s more that people are not used to it. Like bad kerning, it’s something you’ll notice everywhere if you train your eye to look for it, but otherwise probably don’t notice except that some things feel less appealing.

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

#179

Post by nulld3v »

izacus wrote: post #149
account42 wrote: post #143

Earlier quoted context omitted.

What a shit take. JXL did have plenty favorable responses on HN before Google removed it for reasons that they never applied to their own formats. And FF did get plenty of complaints for not supporting JXL but those are often shut down with the opposite variant of your take.

As I work with codecs I've been following the situation quite closely and the attention to XL was pretty much zero until Google decided to not support it. Moreover, this whole topic is about a comparison over a SINGLE IMAGE. Anyone who ever came close to codecs would immediately dismiss this as ridiculous. Yet here we are.

I will respond to you since you posted about this so called "SINGLE IMAGE" three times in this post already.

Ackchually, the blog post contains a comparison over TWO IMAGEs. But since you work with codecs, surely you understand that the blog post is complaining about how WebP interacts with gradients in general and not just about the specific images in the blog post.

JXL was getting plenty of attention before the Chrome debacle. Of course it was less than WebP and AVIF but JXL wasn't getting pushed or championed by anyone (other than Cloudinary I think) so JXL didn't have the marketing powers the others had.

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

#180

Post by djha-skin »

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…

I too am on Android.

I was able to see it without full screening.

Look at the man with his face screwed up. Look at the edges of his shirt near his shoulders.

In the pictures that had bad image quality, there is a sort of glow around his shoulders, as if they are backlit.

In the pictures that had a good image quality, The gradient was smooth. There was no backlit glow around his shoulders; it just looked like a smooth gradient background image.

To be clear, I'm not a photographer. I'm a DevOps engineer. The last time I professionally wrote a line of JavaScript was at least 11 years ago.

It's easy enough to see.

Post reply on HN