5 ms·
WebP - A new image format for the Web (by Google)
- alt_ 14y ago"New" Blog announcement: http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html http://blog.chromium.org/2010/09/webp-new-image-format-for-w... Earlier discussion: http://news.ycombinator.com/item?id=2569881 http://news.ycombinator.com/item?id=2569881
- rb2k_ 14y agoWebP is 2 years old by this point in time. Is there anything new that I missed?
- themgt 14y agoYeah, from poking around the history, looks like Google has just about got added (but not tagged into a release - 0.1.3 is still current) all the features Mozilla saw as blockers previously, so it's possible the format could be added to Firefox and start seeing more traction soon https://bugzilla.mozilla.org/show_bug.cgi?id=600919 https://bugzilla.mozilla.org/show_bug.cgi?id=600919
- zokier 14y agoMaybe a demonstration of its (lack of) success, if people do not even remember it anymore :)
- beggi 14y agoExactly, is and will stay irrelevant for web developers until it gets adopted by more browsers. Google displays PNG still today on Google.com for Chrome users.
- rollypolly 14y agoNot just browsers, but all image editors (natively) like Photoshop. But at its core, WebP hasn't been shown to be more than marginally better than JPEG, so why bother modifying your tool chain and work flow? You generally need something to be an order of magnitude better for people to bother.
- mirsadm 14y agoWebP support transparency with lossy compression which is a huge advantage over JPEG. When I was studying image compression back at university we wrote a whole bunch of lossy/lossless codecs. The issue is that most of the cool algorithms are protected by patents (such as Arithmetic coding). JPEG is quite old now and you can achieve much better results with wavelet coding as opposed to the traditional DCT approach. Plus it doesn't suffer the horrible blockiness effect that quantized DCT based stuff does. Edit: If anybody has a few hours of time to waste here's a thesis I wrote on deblocking JPEG images a long time ago. http://www.csse.monash.edu.au/hons/projects/2005/Mirsad.Makalic/thesis.pdf http://www.csse.monash.edu.au/hons/projects/2005/Mirsad.Maka...
- mistercow 14y ago> such as Arithmetic coding Isn't range coding widely viewed as being a legitimate workaround for the arithmetic coding patents? I guess in a year or two the question will be irrelevant, as the last of those patents will expire soon.
- danmaz74 14y ago"jpeg" with transparency would really be a boon...
- ZeroGravitas 14y agoI was under the impression that Wavelets were something of a dead-end. As far as I picked it up the wavelets need to be tuned for your output. People have tuned them for great PSNR output but not for SSIM or other perceptual outputs so you get output that is blurry sometimes even compared with JPEG. I'm not sure if this is a fundamental problem with the technique, or just something that's currently impracticable compared with less elegant but working alternatives. There's more here (though it's talking about video issues too): http://x264dev.multimedia.cx/archives/317 http://x264dev.multimedia.cx/archives/317
- annon 14y agoYeah, I feel the slight advantages it brings to the table are easily overwhelmed by the fact that I have to carry two sets of images, and use browser detection to switch between them. Even if Firefox and IE picked it up, their older versions are still not going to support the format. This makes it not very useful for at least 4-5 years.
- joshfraser 14y agoYou can also use a service like http://torbit.com http://torbit.com to create copies of all your images and serve up the right version to each browser that visits.
- cabirum 14y agoNo one needs smaller images anymore. With today's bandwidths getting higher, image sizes are irrelevant. One-time 25% decrease in image size, years in development and more years to widespread adoption, not worth it.
- ronaldj 14y agoYes yes yes we do! Bandwidth may be increasing, but as displays get better we are going to be serving up ever increasing assets. Sites are already serving up 2x'd versions of images for iOS devices that have higher resolution screens. These higher res images essentially quadruple your file size. On top of that these devices are mobile, which lag behind broadband/ethernet connections AND many of which have data limit caps.
- pornel 14y agoSizes of "Retina" PNGs can be halved just by using better PNG compressors, here's real-world example: http://imageoptim.com/tweetbot.html http://imageoptim.com/tweetbot.html It's annoying that we have the tools. We don't need new format for this, just use what we have already!
- ronaldj 14y agoBut you won't get the file size of a lossy WebP image with an alpha channel.
- VikingCoder 14y ago"Amazon found that it increased revenue by 1% for every 100 milliseconds of improvement."
- ahoge 14y agoWe don't have a lossy RGBA image format. WebP is about 20% of the size of a PNG32 image. That's a pretty big deal.
- ChrisNorstrom 14y agoEven if it's significantly better, do the means justify the ends? On massive sites with millions of images, like flickr or facebook, converting all their jpegs into webps to save on bandwidth and speed would mean that they would have to duplicate every single jpeg image (keep the jpegs for older browsers) with a webp copy to serve to newer browsers that support webp. But by doing that you're nearly doubling the HD space of the entire service. More HDs, more servers, more electricity, more personnel. So whatever money was saved on bandwidth (which is getting cheaper all the time) is negated by the architecture required to pull off the transition. I feel like this is one of those: "good inventions that are better than the competition but have no demand from the market."
- ronaldj 14y agoI think that for some interactive content, we could do definitely utilize WeP's lossy alpha channel format. The one thing that pops up in my mind are filmstrip animations, where you make a animation using JS and a single image that has all your frames. This allows you to control its playback with JS and gives you better image quality than GIF. Right now we can use JPEG compression for this, but this means we have to bake the page background into the frames or use a huge PNG. With enough browser support an animation like this could just fallback to a single PNG for older browsers and newer browsers would be better experiences.
- VikingCoder 14y ago"Amazon found that it increased revenue by 1% for every 100 milliseconds of improvement."
- ronaldj 14y agoWe could make the web a lot faster and/or do some really cool stuff if we had a lossy image format with an alpha channel. It'd be nice this got picked up by all browser vendors. Sadly, I fear that they'll be squabbling over it, just like they are with VP8/Ogg/h.264. I really believe that the companies involved in web standards are holding progress back at this point. At the same time, even if they all agreed to put this in tomorrow, we'd still be stuck supporting IE6-9 which will never have it. Being a web developer sucks sometimes.
- ahoge 14y agoWe had such a format. It was called JNG. It's a JPG/PNG bastard which allows you to combine PNG or JPG color channels with a PNG or JPG alpha channel. Typically, it's around 20% of the size of a PNG32 image. Unfortunately, Mozilla killed the format back in 2003, because the MNG (JNG is a subset) library added about 100kb to the installer. Yes, that was the primary reason. Their suggested alternative was to use Flash instead. https://bugzilla.mozilla.org/show_bug.cgi?id=195280 https://bugzilla.mozilla.org/show_bug.cgi?id=195280 (Note: The sizes of the libraries are the uncompressed sizes. The uncompressed size is completely irrelevant.)
- sitkack 14y agoreading that bug report made me cry. The use of MNG in one session of web browsing would have saved more bandwidth than used by the extra space in the installer. wtf.
- ahoge 14y agoThose fancy single page sites with lots of parallax effects and transformations often have 4-5 MB worth of PNGs. With JNG you can easily push it below 1 MB. (I tried this with several websites.) To make matters worse, if you just support JNG and not all of MNG, you'd add maybe 5-10kB. The PNG and JPEG decoders do all of the heavy lifting. You'd just need a little bit of extra code for taking the file apart and splicing the channels together. All of the tricky stuff is already there.
- 14y ago
- baq 14y agorequired reading: http://x264dev.multimedia.cx/archives/541 http://x264dev.multimedia.cx/archives/541 - don't know how relevant it is now, but still a good read.
- magicalist 14y agoThat article is about the old encoder, though, and it's almost two years old. It ends with an update from a year ago in which he mentions that the new (at the time) encoder in libwebp should beat jpeg.
- rorrr 14y agoSo I downloaded libwebp-0.1.3-windows-x86.zip, there is cwebp.exe inside. I can't figure out how to compress PNGs losslessly into WebP. These are the options it gives: Usage: cwebp [-preset <...>] [options] in_file [-o out_file] If input size (-s) for an image is not specified, it is assumed to be a PNG or JPEG file. Windows builds can take as input any of the files handled by WIC options: -h / -help ............ short help -H / -longhelp ........ long help -q <float> ............. quality factor (0:small..100:big) -preset <string> ....... Preset setting, one of: default, photo, picture, drawing, icon, text -preset must come first, as it overwrites other parameters. -m <int> ............... compression method (0=fast, 6=slowest) -segments <int> ........ number of segments to use (1..4) -size <int> ............ Target size (in bytes) -psnr <float> .......... Target PSNR (in dB. typically: 42) -s <int> <int> ......... Input size (width x height) for YUV -sns <int> ............. Spatial Noise Shaping (0:off, 100:max) -f <int> ............... filter strength (0=off..100) -sharpness <int> ....... filter sharpness (0:most .. 7:least sharp) -strong ................ use strong filter instead of simple. -partition_limit <int> . limit quality to fit the 512k limit on the first partition (0=no degradation ... 100=full) -pass <int> ............ analysis pass number (1..10) -crop <x> <y> <w> <h> .. crop picture with the given rectangle -resize <w> <h> ........ resize picture (after any cropping) -map <int> ............. print map of extra info. -d <file.pgm> .......... dump the compressed output (PGM file). -short ................. condense printed message -quiet ................. don't print anything. -version ............... print version number and exit. -noasm ................. disable all assembly optimizations. -v ..................... verbose, e.g. print encoding/decoding times Experimental Options: -af .................... auto-adjust filter strength. -pre <int> ............. pre-processing filter
- aw3c2 14y agothere is a webp file in my video directory on my android. timestamp is 02:30 Saturday night. I do not have the slightest idea where it came from or what I did then. a shame because I have never ever encountered one elsewhere.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- salimmadjd 14y agoFacebook should support this in their native mobie apps. I'm sure they have to creat multiple copies already to support both mobile and web. So there is no extra cost and since they control mobile viewing it's easier for them than anyone else to adopt this new format.
- ZeroGravitas 14y agoI assumed this was posted because they just redid the lossless support, but it's just a general link and the conversation has been therefore unfocused. The PDF describing the new lossless mode is here: http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=blob_plain;f=doc/webp-lossless-format-spec.pdf;hb=experimental http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=blob_pl... It seems quite neat to me, particularly the way they encode the compression info as images though maybe it's just standard lossless image techniques, I'm no expert. As for the format generally, I think better lossy compression than JPEG, better lossless with alpha compression than PNG, better animation than GIF, and a lossy with alpha mode and hardware encode/decode support is a reasonably powerful combination. Support from Chrome and Android means it's probably got niche uses already (on or off the web), support from Mozilla (which I'd like to see, since generally multiple vendors working together on something makes me happier, and seems to produce better end products, than one going it alone) could make it a standard practice for those trying to squeeze extra performance out of their web sites, which in turn disadvantages browsers that don't have it. In the longer term there's probably going to be a shift sooner or later and webp is well placed by getting in early. Even if something better comes along later (and there does seem some kind of limit to the possible improvements), it'll have widespread installation on its side like png/jpeg/gif/etc. have today.