We 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.<p>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.
Even 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.<p>I feel like this is one of those: "good inventions that are better than the competition but have no demand from the market."
I 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:<p><a href="http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=blob_plain;f=doc/webp-lossless-format-spec.pdf;hb=experimental" rel="nofollow">http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=blob_pl...</a><p>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.<p>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.<p>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.
Facebook 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.
No one needs smaller images anymore. With today's bandwidths getting higher, image sizes are irrelevant.<p>One-time 25% decrease in image size, years in development and more years to widespread adoption, not worth it.
required reading: <a href="http://x264dev.multimedia.cx/archives/541" rel="nofollow">http://x264dev.multimedia.cx/archives/541</a> - don't know how relevant it is now, but still a good read.
there 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.
So I downloaded libwebp-0.1.3-windows-x86.zip, there is cwebp.exe inside.<p>I can't figure out how to compress PNGs losslessly into WebP.<p>These are the options it gives:<p><pre><code> 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</code></pre>