Hacker News new | comments | ask | show | jobs | submit login

I can understand Google's reason for making and promoting WebM, but is there really a need for another image format? Yes, it may be X% smaller than JPEG for the same image quality, but does that really matter? Compared with video, the bandwidth for serving images is practically nothing, and even with universal adoption by browser and operating system vendors it will still be years before you can rely on all your clients having WebP support.

I don't think there's any reason not to try to improve something even if its satisfactory. Image formats are no exception - I don't think JPEG is the best that can be done and I hope we have better options moving forward.

It doesn't matter. Get over it. Leave it alone. Let it go.

There is a need for better image formats for photography, for gigatextures, for voxels, for specialized cases, but not for general web use. This problem is solved. Move along.

ASCII has served us well, it's still used now, and even though it's broken in a lot of ways, UTF-8 addresses most of those to a degree that's satisfactory enough we don't need people inventing new character encoding systems.

Between GIF, PNG and JPEG you have what you need. Don't cry over a few wasted bytes or a few smudgy pixels.

I could say the same thing about H.264. Why should we bother making better video codecs for general movie viewing use? Let it go. We can just add more data layers to Blu-rays.

And it's not like JPEG or ASCII or UTF-8 or anything we use today is going to suddenly disappear if we add new browser support. Why not strive for excellence?

Tell that to Flickr, Wikimedia, Facebook and a large portion of the developing world that are stuck on slow and expensive mobile connections.

That was sarcasm, right?

Come on HN, he makes a justifiable point quite well; this doesn't deserve downvoting.

FWIW I disagree strongly with his sentiment.

Previous discussions: http://news.ycombinator.com/item?id=1744237 http://news.ycombinator.com/item?id=1746621 http://news.ycombinator.com/item?id=1745801 http://news.ycombinator.com/item?id=2507700

It may be X% smaller than JPEG for the same image quality, but does that really matter?

If the bandwidth cost saved is greater than the cost of adding WebP to Chrome, then it's a net win. Or if it makes some Google page load 10 ms faster, that would also pay for it.

years before you can rely on all your clients having WebP support.

That's what content negotiation is for.

The problem is that Chrome sends an accept header of / for images, meaning that mod_negotiation for instance can't determine what to send. The only real way is either by hard coded UA sniffing on the server (uggh!) or by detecting webp in JS (ugggh!) as far as I can tell.

It does matter when a lot of web browsing happens on mobile.


Majority of the mobile phones will only have access to 2G/3G speeds.

In a lot of countries, mobile data is metered. Saved bytes = saved money.

A cool option for mobile browsers, would be that an online service, could convert JPEG files into WebP. Then the mobile browser could be downloading the WebP file instead - that way saving money.

Opera (and others I think) does this with JPEG quality. They mirror the image files as far lower quality JPEG so as to improve speed for those on limited bandwidth. You can of course request the full files.

Correct. If you enable Turbo in Opera Mobile or desktop, all traffic is sent through a proxy server which converts images into WebP format. The quality is better than when we used jpegs and the file sizes are much smaller. (Disclaimer: I work for Opera)

If X was less than 10, you may have had a point. But a 39.8% decrease in size is substantial.

So, yes, it does really matter

PNG had similar issues with browser adoption. The huge thing about WebP for me is it's support for transparency (which it was planned to support last time I checked).

I think the lack of transparency right now is what prevents me from caring enough to use it. Compression along isn't enough of a win.

Alpha-channel support is in the trunk, marked as experimental, so I think it's coming soon.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact