

Lossless and Transparency Encoding in WebP - valyala
http://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html

======
pavpanchekha
This is incredible! If the claimed benefits are true (and the WebX team seems
to be pretty honest about their numbers) this is now a better format than PNG,
JPEG, and GIF, all at once, as well as covering some other options (lossy +
transparent) that could be interesting. WebP, with recent metadata and ICC
support, and these new additions, is starting to look like a serious image
format that we might have good reason. If Google can encourage Firefox to
start supporting it, it might even see significant usage. Just think --- one
image format covering all the use cases you care about, one optimization tool,
one backend to thumbnail user images, you name it.

Man, PNG was such a nice binary format, though. _sniff_

~~~
gcp
1) Quoting source page: "The bit stream specification has not been finalized".
This is something other implementers want to stay clear from for now, let
alone it gets deployed in the wild and you have massive compatibility issues,
or need to bloat all supporting software to support now-long outdated
bitstreams (hi Vorbis!).

2) "If Google can encourage Firefox to start supporting it". Yeah, like they
did with WebM, and then completely backstabbing Firefox by never actually
removing H.264 support from Chrome, despite claiming to going to do it for
many months. If the Firefox developers don't have total amnesia, I think
they're going to need a lot of encouragement.

~~~
ZeroGravitas
point 2 is just a little overdramatic considering all the other support that
Google offers for WebM e.g. buying it for $130 million in the first place,
supporting it in Chrome and Android, converting the entire Youtube back
catalog, producing reference hardware encoders and decoders and giving the
designs away for free, etc. etc.

Chrome and Firefox in desktop and Opera and Android in mobile have enough
combined share to shift the market on this if they want to. I'd hope and
assume that Mozilla's decision making would be a bit more related to their
mission to support an open web than to petty recriminations for percieved
slights.

~~~
gcp
_Chrome and Firefox in desktop and Opera and Android in mobile have enough
combined share to shift the market on this if they want to._

Yes, meaning dropping support for H.264. Firefox did this, Chrome did not (I'm
not sure what Opera does?). What's the conclusion? Google doesn't particularly
care to shift the market in favor of their own format, or thinks it will burn
its other fingers too much in doing so. Meanwhile, H.264 is used everywhere,
including for Firefox users, who get to enjoy it over the now-deprecated
Flash.

Do you see a problem looming here for "supporting the open web"?

 _I'd hope and assume that Mozilla's decision making would be a bit more
related to their mission to support an open web than to petty recriminations
for percieved slights._

Does WebP advance an open web? Let's see, is there some actual standard
describing it, or do you have to blindly lump in a big chunk of Google code to
support it? (That's a real question)

~~~
ZeroGravitas
I actually meant WebP when I said they could move the market on their own. I
think that WebM has a slightly harder hill to climb and would require
Microsoft, Apple or Adobe to get fully on board, but that WebP adoption would
also help ever so slightly in that regard too.

(Opera, who originally proposed the video tag, with a suggestion to use Theora
as the only viable video format at the time with licensing compatible with the
web, didn't drop H.264 because they never supported it. I mentioned them in
this context because they already support and use WebP in their bandwidth-
saving page-transcoding features which are particularly useful in mobile
devices on 3G networks. This solves the chicken and egg problem and gives
browsers, like e.g. Amazon's Silk, a reason to support WebP even if no-one
uses it yet.)

edit: and to answer your last question, WebP was up until recently a subset of
WebM, which can be decoded by at least two other independent implementations I
know of (FFMPEG and one in Java). Standards settings bodies have been
corrupted by politics and are no match for multiple, independently produced,
open source codebases.

------
richbradshaw
Finally! A lossy transparent format, supported by a browser that a large % of
people use!

Does anyone know a good way to provide webp with a fallback, short of sniffing
the UA? I've tried using mod_negotiation
(<http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html>), but Chrome
doesn't sent the webp mime type, so I can't get it to work...

Anyone know of a solution?

~~~
maggit
This is what the Accept-header is for, but unfortunately browsers do not
really give helpful values in this header.

I've also heard from people working with web browsers that the Accept-header
wouldn't work well for the real web anyway. Sigh. :(

------
rvavruch
Chicken and egg. Designers will not use a format not supported by the majority
of browsers and browsers see no need to implement new formats unless people
are asking for them.

It goes against the web design principle of making your site usable to all
users regardless of what they are browsing with to use an image format that is
not widely supported. This principle is backed by users who will simply leave
your site in disgust if they are asked to jump through hoops to use it. Very
few designers will be willing to maintain two versions of all their images
just because one of the formats is a bit smaller.

Microsoft has it's own range of newish web image formats that never caught on.
History suggests IE is unlikely to support anything "not made here" unless it
is forced to. The competition to Microsoft's image formats, JPEG2000, never
caught on either. Firefox has an infamous open bug about adding it in dating
back to 2000: <https://bugzilla.mozilla.org/show_bug.cgi?id=36351> \- over 11
years! Despite what it looks like in the last comment, my Firefox 8 still does
not have support.

The last image format that managed to make it was PNG, and that was almost
over a decade ago, although alpha support in PNG was added comparatively
recently to IE. Last time I checked MNG (PNG's answer to animated GIFs) still
wasn't widely supported.

Sorry to be such a downer, lack of support for JPEG2000 was a let down for me.
As I see it Firefox, Opera and Safari will all need to support this first,
before web designers in general will even consider using it. Only once a
significant number of web designers are clamouring for it will IE slowly add
support for it. Only then will it see wide use.

Tool support is vital too, most importantly Adobe PhotoShop. No web designer I
know of is going to muck about in the commandline with imagemagick.

~~~
wladimir
Those formats aren't really dead. Just that the web browsers don't support
them doesn't mean they're not used.

mng is currently used for simple animations in UIs (for example, Qt has built-
in support for it). On the web, I guess there just isn't that much of a need
for an animated format (other than fully-fledged movies).

jpeg2000 is used by some 3d tools and games as texture/asset format.

WEBP already has the advantage that it has been implemented by one of the
larger browsers, and that it supports _everything_. Lossy, lossless,
transparency, animation. And smaller files as a bonus. It could be the image
format to end all image formats :-) I can see a lot of uses outside the
browser as well, even if it fails as browser format. I also think google is
going to push it as the defacto image format for Android.

Support in design tools isn't that important. One can always convert image
formats as part of deployment. In many cases this is needed anyway (for
example for CSS spriting / inlining).

------
morsch
When reading about this I came up with the idea of rendering a JPEG on a
canvas element with a PNG (or grayscale JPEG) as a transparency map. This
would give you alpha-channel JPEG on most browsers _right now_. Sweet huh?

... and of course, it's been done: <http://jim.studt.net/jpeg-alpha/> :) It's
even been on Hacker News, though not to much attention:
<http://news.ycombinator.com/item?id=1772760>

------
pornel
WebP's compression is good, but there's an often forgotten PNG8+alpha format
that is a form of lossy compression as well.

Although PNG8+a compression isn't as good as lossy WebP, it is availble _now_
, and it is compatible with all browsers.

Comparison: <http://pngmini.com/vs-webp/>

Source code: <https://github.com/pornel/improved-pngquant>

------
sp332

      * flashes the DarkShikari signal *
    

:)

I wonder if just adding LZMA or PPMd compression to PNG (instead of deflate)
would have the same size improvements, with the benefit of keeping PNG's very
nice binary format.

