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.
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.
I, too, would like to see other browser vendors follow and I don't see the same obstacles as with video codecs so there's hope yet. Microsoft's plans for IE auto-updating should also help (if they decide to support WebP) but admittedly it'd still be a long wait for web developers.
We (Opera) started supporting WebP not long after its release and it's proved to be an effective improvement on JPEG. IIRC, there's a roughly 30%-40% reduction in image filesizes when used as part of our server-side compression feature (Turbo) which converts all JPEGs into WebP (among other stuff).
Of course, support in all modern browsers and being able to use WebP exclusively in public sites are not closely connected, unfortunately, but for sites with high image usage, detection for support and server-side image replacement could be worthwhile.
I've actually used this technique before. You can also use an SVG clip path to do something similar in Firefox. When I used this technique I shipped the mask as a separate file as I wasn't familiar enough with the file format to realize I could attach it. The 63KB limit when attaching the mask to the image might be too close.
If you make an app that can take a PNG and convert it to JPEG with alpha channel can you let me know? I would be VERY interested in this.
We 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.
Good god, that was INFURIATING. Let me summarize it:
Dev 1: MNG sux, lol. It's like, 100kb of wasted space.
Many Users: MNG is good, and the space is nothing!
Dev 1: Oh...well, lol, I'm bored maintaining it.
User: I wrote the library and I'll maintain it!
Dev 1: Oh, lol. MNG sux, and you suck too. Just use Flash or gifs, k?
Many Users: Those are proprietary and patent encumbered, and MNG has features they don't anyhow. This will break a ton of stuff, including the default theme! And MNGs are used a ton in Asia!
Dev 1: ...whatever, lol. Only losers use MNG, and I'll make a new gif for the theme.
Dev 2: Sounds good to me! Say goodbye to MNG support, losers.
Dev 1: lol!
Meanwhile, Firefox is still bloated, there's still a need for something like MNG, and Chrome is busy eating Firefox's lunch in large part because of the exact behaviour displayed on that bug.
sigh It makes me want to slap the two people involved. That thread should be used in a textbook of "how open source projects become large, bloated, and end up being run into the ground via a concerted effort to annoy users and keep people from joining the dev team". I don't think I've ever seen such a concerted effort to try and discourage a potential maintainer and rip out perfectly working useful code before.
reading 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.
Those 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.
After reading this bugzilla thread, I searched and came across this interview with Stuart Parmenter, the Mozilla dev who essentially removed support:
--------------------
Parmenter: ...One of the probably biggest sort of conflicts was when-so I actually sort of own the MNG library I guess, and all the de-coders and everything. So we had this module owner system, so I guess I'm the module owner of that. And at some point, we had checked in this de-coder for the MNG format which is a multiple network-or I don't know what it stands for.
But it's basically animated PNGs. So animated GIFs were all the rage with, you know, I don't know, 1998 websites or something. And they-but GIF is basically is indexed formats and it only supports 656 colors and it only works with one bit alpha transparency. So either the pixel is there, it's not. Versus PNG, which has full-it has eight bit alpha support. So you can have 256 levels of alpha so you can-things can be translucent. As well as true color support. So you can see as many colors as you want. So basically, you try to do that.
But then something went wrong and they decided that it also needed to do all these things that, like, Flash can do. So it needed to sort of be a movie format and then it-it kind of went-something went wrong at some point. GIFs are very simple, animated GIFs are easy and they-it was basically a very big and complex thing. (emphasis added)
And then after having it in our product for, like, two or three years, we did some searchers and there were, like, fifty of these images on the web. So we decided-you know, we said, this is silly, this is like, four hundred kilobytes, you know, which was, like, three times bigger than all the other de-coders and the image library combined.
So we said, you know, this is-we don't need this anymore. So I removed it and we had a huge uproar. People were, like, "We can't believe you removed this, you know." It's, like-it was one of the, I think, probably one of the few cases where we've really gone in and said, "We're going to remove a feature that we had before." People apparently don't like that.
So I removed that. We had a lot of uproar and people said, "You know, why did you do this?" We said, "You know, we have this set of reasons. It's too big, it's too slow, it's-nobody's really actively maintaining it." What had happened is, the guy who was sort of working on it also said, "We should remove this." But then sort of the maintainer of sort of one of the MNG libraries and stuff that we were using said, "No, No, this is-you know, we'll get this fixed."
And it kind of got ugly for a while. But effectively what ended up happening was, we sort of have a system that's called a "drivers" which sort of-I guess they're in charge of the product releases and stuff or were. And sort of-it got raised up to there and in the end they sort of said, because I sort of said a thing. I said, "You know if you guys can get it under this size and you can do all these things, we'll take it, whatever."
But they never really did. And so they complained and complained and complained and they're still complaining to this day and this was, like, three years ago. So, you know, but in the end, driver said, "You know, figure out how to meet these requirements. Get an active maintainer, do these things." And nobody really has. They've made some effort but it's not really where we wanted to see it go.
I don't think they were really interested in meeting some of the requirements. I think they said, "You know, this is-." They were kind of just trying to chop random bits out and sort of mess with the functionality as opposed to sort of really reducing the size. (emphasis added)
So we got rid of it. A lot of people were mad and, you know, it just sort of-in that case, it just sort of-we just decided that was the right thing to do. But I think in other situations, you know, I think a lot of times it's sort of just very small. Like, I mean, that's kind of a big argument. But you get into a lot of much smaller ones about just kind of minor things or design things, architectural things.
--------------------
Attempting to even read this was infuriating (thanks to the verbatim transcription of none-too-eloquent speech), but it galls how some of the devs seemed anti-progress at the time. Cut off a new format with low adoption but a promising featureset, because Flash, a non-open plugin, could be used to achieve similar functionality? Would they have opposed CSS3 transforms and animation at the time, too?
The paragraphs I italicized shows how this guy thought the featureset was basically pointless - as far as I can tell from his fragmented speech, anyway - and that the size was a big deal. What I get from this is that he thought it wasn't a useful format, and so size was used as a justification to remove it.
Many salient counter-arguments were raised in that thread but essentially rejected out of hand without any engagement. Mozilla might not be a democracy, but it would have behooved them to listen to users/contributors/stakeholders more in this case.
What keeps one from implementing a pure javascript implementation that renders to canvas? Do we need browsers to support formats anymore? With WebGL, WebCL, high speed JS and the canvas tag don't we have everything we need?
(There's also a shortcut in browsers like Firefox that support WebM and not WebP where you can turn a WebP file into a single frame WebM video and display it to canvas).
I would imagine that's a good route for lesser known image and audio formats (possibly even video formats) and backwards compatability but I'm not sure it's currently ideal for most image decoding on the web.
Someone should really try it out and see though, it's probably only a matter of time before things like this start moving into javascript.
Sadly, very few people know about it and make good use of it. Mostly it's lack of awareness and dominance of poor/outdated tools (cough Photoshop cough) that don't fully utilize formats we have.
Those are really nice, and the gallery goes a long way toward making the case for it.
It's worth underlining the fact that "lossy" here means "really nicely dithered 256-RGBA-palette PNG8s", but (as the gallery examples demonstrate), that may be sufficient for most of the kinds of images that have significant transparency and that would be likely to be found on a webpage (even sprites for a canvas game).
Honestly, I would still like to see WebP support in spite of its drawbacks (thanks software patents!) for it's better definition of "lossy" and for saner alpha compression, but between better pngs from software like this and upcoming support for DXT5 in WebGL, most of the compelling market drivers may be gone.
There's also a second option — adaptive posterization — that reduces PNGs by ~30%. Useful for images that are too "colorful" for 256-color RGBA.
WebP is a fine format, but establishing a new format on the web is really hard. There's a graveyard of better JPEGs, and after 16 years since PNG was published, GIF is still alive and well. http://ycombinator.com/images/y18.gif
The web has strong preference for "good enough that works everywhere". IE6 was enough to discourage devs from using PNG, nad you won't see Google's WebP in IE or iOS anytime soon.
Nowdays you can decode WebP with JS, but size of a JS decoder and CPU time to run it will most often offset any savings from the format.
You'd probably be OK as long as the alpha extremes (0 and 255) were lossless; everything in between could probably cope with being slightly off, especially if you could control the quality of alpha and YUV separately, and the YUV quality was (somewhat) weighted by alpha, with a 1 pixel "border" into transparent areas to support interpolation when scaling. Lossless alpha and lossy YUV is already a major improvement over the status quo, however.
Artifacts in the alpha channel are surprisingly subtle. Well, it makes sense if you think about it: The opacity is low, which makes those little details very hard to see.
A gray-scale JPEG with medium quality (even if it was written by a somewhat crude encoder) will look perfect if used as alpha channel in the vast majority of cases.
Yeah, 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
Exactly, 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.
Yeah, 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.
Not 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.
WebP 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.
I 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.
That is a big problem with the wavelet based approaches. They tend to be tuned for impressive PSNR numbers which doesn't always correspond well to perceptual image quality. I haven't seen that article in a while and he raised many valid points.
I think wavelets do have a future but it will just take more time and research. I'm not too sure what the state of it is at the moment as it has been a while since I've looked into it. It is my opinion that in time wavelet based compression will become more important though.
Edit: I forgot to mention that one really cool thing about wavelet codecs (for video especially) is that they are easy to scale by decoding portions of the bit stream. This is really useful for streaming as you can vary the image quality without too much work.
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.
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.
I feel like this is one of those: "good inventions that are better than the competition but have no demand from the market."
I 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.
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:
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.
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.
Yes 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.
That 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.
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.
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
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.