
WebP - A new image format for the Web (by Google) - marcusEting
https://developers.google.com/speed/webp/
======
ronaldj
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.

~~~
ahoge
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.

<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.)

~~~
creamyhorror
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.

~~~
ahoge
Oh boy, that "interview" was horrible. I now got a headache and want to punch
something.

------
rb2k_
WebP is 2 years old by this point in time. Is there anything new that I
missed?

~~~
beggi
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.

~~~
annon
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.

~~~
joshfraser
You can also use a service like <http://torbit.com> to create copies of all
your images and serve up the right version to each browser that visits.

------
alt_
"New"

Blog announcement: [http://blog.chromium.org/2010/09/webp-new-image-format-
for-w...](http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html)

Earlier discussion: <http://news.ycombinator.com/item?id=2569881>

------
ChrisNorstrom
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."

~~~
ronaldj
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.

------
ZeroGravitas
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:

[http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=blob_pl...](http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=blob_plain;f=doc/webp-
lossless-format-spec.pdf;hb=experimental)

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.

------
salimmadjd
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.

------
cabirum
No 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
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.

~~~
pornel
Sizes of "Retina" PNGs can be halved just by using better PNG compressors,
here's real-world example:

<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
But you won't get the file size of a lossy WebP image with an alpha channel.

------
baq
required reading: <http://x264dev.multimedia.cx/archives/541> \- don't know
how relevant it is now, but still a good read.

~~~
magicalist
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.

------
aw3c2
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.

------
rorrr
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

~~~
wmf
Did you try -q 100? That might be an idiom for lossless.

~~~
rorrr
I did, and it produced a huge .webp file, 6.7 times larger than the original
PNG.

~~~
salmanapk
rtfm? Check the examples at the bottom:
<https://developers.google.com/speed/webp/docs/cwebp>

~~~
rorrr
Did you read that link yourself?

The word "lossless" isn't even on that page. I tried setting the highest
quality, but that just produces huge files.

