WebP - A new image format for the Web (by Google)(developers.google.com) |
WebP - A new image format for the Web (by Google)(developers.google.com) |
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.
Just what I thought last time this came up. Built it. No one came.
http://jim.studt.net/jpeg-alpha/
(I haven't looked at that code in 18 months, but it explores some options and lets you have JPEG images with alpha channels in your browser.)
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 (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.
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
(Note: The sizes of the libraries are the uncompressed sizes. The uncompressed size is completely irrelevant.)
--------------------
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.
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.
http://libwebpjs.hohenlimburg.org/vp8/webm-javascript-decode...
(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.
We do!
http://pngquant.org & http://pngmini.com/vs-webp/
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.
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.
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.
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.
Blog announcement: http://blog.chromium.org/2010/09/webp-new-image-format-for-w...
Earlier discussion: http://news.ycombinator.com/item?id=2569881
I feel like this is one of those: "good inventions that are better than the competition but have no demand from the market."
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.
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.
One-time 25% decrease in image size, years in development and more years to widespread adoption, not worth it.
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!
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 filterhttp://code.google.com/p/webp/downloads/list
I think png2webpll.exe is the one you want (webpll = webp lossless).
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.
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.
The word "lossless" isn't even on that page. I tried setting the highest quality, but that just produces huge files.
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.Maka...
There's more here (though it's talking about video issues too): http://x264dev.multimedia.cx/archives/317
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.
