Live data from Hacker News

Is WebP really better than JPEG?

siipo.la

291–300 of 319 posts

Re: Is WebP really better than JPEG?

#291
post #157

Earlier quoted context omitted.

What’s interesting is that Google’s Lighthouse tool for measuring site speed pushes for “Next Gen” image formats like WebP. But I often find that WebP files are larger than jpg, too. Yet Lighthouse recommends it. And, of course it’s a great idea to follow Google’s advice since they include the Lighthouse score in their ranking algorithm.

The irony is that the Lighthouse site itself scores really badly! Can you accept its advice?

Idk. I optimized the end-user facing part of my website heavily, while the backend part (which is used only by a few people), I don't really care. I didn't even minify the JS.

Re: Is WebP really better than JPEG?

#292
JPEG quality can probably be better (but slower) when using sophisticated decoder libraries. This way, a JPEG image with a WebP size may look with the same quality. But I didn't test.

https://news.ycombinator.com/item?id=22245788

Also, Google has a "brunsli" library, that can recompress JPEG to JPEG XL format without loss.

https://google.github.io/brunsli/

Re: Is WebP really better than JPEG?

#293

It's all about Google wanting control. Their own file formats, their own protocols, AMP, not showing URLs in Chrome. The goal is to turn the web into a closed Google ecosystem.

How does a royalty-free codec with an open source implementation turn the web into a closed ecosystem?

Not that I trust Google, but in this case I don't see the harm.

Re: Is WebP really better than JPEG?

#294
What really sucks about all this is that they're actually ruining the credibility of lighthouse audits this way; what has been for years the best all-in-one automated performance+accessibility analysis tool for any web app/site and is now being used to promote some random new image format no one wants to care about.

You spend all this time improving your stack, reducing your app bundle size, convincing your company on the benefits of server side rendering, improving your devops, getting your manager to see these measurable benefits by running lighthouse audits themselves etc...

Then all of a sudden it turns out that the main tool you used for this has been turned into a.. a fking ad platform.

I apoligise for this emotionally charged rant, but seriously though, is that how you plan on getting developers adopt your dubious new standard, by p*ssing them off?

Re: Is WebP really better than JPEG?

#295
post #289

Earlier quoted context omitted.

How would you show a photographed image as a svg? Either you would have to "vectorize" the image which would look totally different or you'd create a grid of vectors with different hue values, ultimately representing pixels in an extremely inefficient format. Raster graphics and vector graphics can't be compared because sure, you could create 2 million vector squares with individual positions, sizes and colors and al…

Why would you show a photograph as an svg? You wouldnt. Thats what jpegs are for. We're discussing transparency and the use case for it. I dont think ive ever heard of someone wanting transparency in a photo. The only times i see the need is if theyre doing something that is better off in a vector format. I.e. png, which is being supplanted by svg, which alleviates the size problems raised about pngs. I.e. webp is a…

>I dont think ive ever heard of someone wanting transparency in a photo.

OK, but they do. It's pretty common for someone to cut out an object in a photo and have a transparent background.

Re: Is WebP really better than JPEG?

#296
post #113
post #66

I wonder, why nobody mentioned Patrice Bellard's BPG[1]. It is based on HEVC and can be supported in any browser via a Javascript. From his website: BPG (Better Portable Graphics) is a new image format. Its purpose is to replace the JPEG image format when quality or file size is an issue. Its main advantages are: * High compression ratio. Files are much smaller than JPEG for similar quality. * Supported by most Web b…

> I wonder, why nobody mentioned Patrice Bellard's BPG[1]. Isn't it Fabrice Bellard?

Oops, sorry Fabrice, wherever you are.

@als0: Thanks for pointing that out.

Re: Is WebP really better than JPEG?

#297

Summary: - No. It's roughly the same. Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons.

Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons. Pithy comment, and reaction, aside, that's enough to give me pause about implementing it.

*pity

Re: Is WebP really better than JPEG?

#298
post #161

Earlier quoted context omitted.

It's impossible to test for without buying expensive hardware, so I'll pass.

A used iPod Touch is $35, the same price as a Raspberry Pi. Is a Raspberry Pi "expensive hardware"?

Right, I'll put "Designed for used iPod Touch" in the footer then.

Re: Is WebP really better than JPEG?

#299

Earlier quoted context omitted.

Is it better? The AVIF examples in the article look even worse than the WebP ones

At 30% reduced size. The true comparison would be at the same file size, which format is able to squeeze more perceivable information into the same bucket?

Indeed. The article's comparisons seem a bit useless - neither the quality or the filesize is kept constant.

Re: Is WebP really better than JPEG?

#300
post #144
post #127

Earlier quoted context omitted.

How? Do you know how many binaries link to some old version of libjpeg? You're breaking 99.9% of the world and 80% of it is stuff that can't even be recompiled, probably. In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.

All that is true for WebP too, isn't it? If you cannot recompile a piece of software, how are you going to add WebP support to it? And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't h…

You offer two versions:

* A webp version with transparency, which won't be supported by most clients but the ones which do will support everything

* A JPEG version without transparency, or with "faked" transparency (i.e. baked-in background color), which will be supported by basically everyone but with less quality.

That way, if the client is capable of loading the "good" version it will, and if it can't then it will load the "good enough" version.

Post reply on HN