
Mozilla rejects Google's WebP image format - valyala
http://arstechnica.com/open-source/news/2011/05/mozilla-rejects-webp-image-format-google-adds-it-to-picasa.ars
======
teuobk
The one time that I've found a practical application for WebP was when a
client needed to fit a roughly 1-megapixel photograph in less than 5 kbytes of
storage space. JPEG starts falling off a cliff in terms of image quality once
you push it to extreme compression factors (like down near quality-0), but
WebP degrades very gracefully and relatively linearly.

The test images we put together turned into nearly unrecognizable blocky
messes when compressed with JPEG, if they fit at all. The same test images,
compressed with WebP, looked surprisingly decent and were quite usable.

That said, if our photo storage budget had been 10 kbytes instead of 5 kbytes,
JPEG would have been fine for the project's purposes. It was that last little
squeeze that really killed JPEG.

~~~
ZeroGravitas
I remember a trick from the early web days of halving the resolution of a JPEG
and then expanding the compressed result back to the original size. It'll be
blocky, but much less blocky than just reducing the JPEG compression level for
the same fize size reduction at the low end.

I believe WebM does (or at least the format can do) this automatically in low
bitrate situations, without the external user needing to understand what's
happening on the encode or decode end. I don't know if WebP inherits this
trick and that explains it's low bitrate performance or if it's just better in
other ways.

------
HardyLeung
I find that Jeff Muizelaar's argument (not Arstechnica but what they talked
about) very weak. He said WebP is not good because:

* Jpeg has some fancy features not seen in WebP (4:4:4 YCrCb, CMYK support, etc)

* Jpeg's compression is "good enough", and nobody cares about diskspace (cited Facebook 85%, Flickr 96% quality level)

* If WebP, why not Jpeg XR?

* WebP has no alpha channel support!

* There are "low hanging fruit" in Jpeg optimization such as progressive encoding.

Each of these points in isolation may be valid, but together they give me the
feeling that he was arguing surgically. He said Jpeg is already very good,
Jpeg is actually bad but there are low hanging fruit to improve it, and
whether Jpeg is good or bad doesn't matter because nobody cares.

Personally I feel the "75% is already very good" argument to be the weakness.
Facebook pictures are very poor compared to the original, and if diskspace is
not a problem they would have increased it to 96% like Flickr.

I hope Mozilla supports the format and let the users decide.

~~~
jrmuizel
I'd like to respond to your criticism of my argument but I'm having trouble
understanding it.

As for my point about Facebook, I believe that they do care about the size of
the images. However, the fact that they can be trivially and losslessly
reduced in size suggests they just don't care enough to invest in optimizing
them. Presumably, they have more important things to be working on. This
suggests that they might also have more important things to work on than
switching to webp.

~~~
HardyLeung
My apology for not being clear. The five points are summary of what you said
and I hope there is no confusion.

Right after the five points, I object to your "surgical arguments" which is
along the line of "Jpeg is not too bad, and even if it is bad, there are ways
to fix them". The truth is that Jpeg is actually a very poor format. Image
artifact is very poor at low quality, and compression is very poor at high
quality. While I don't know for sure whether WebP is really that much better
at high quality (my limited experience showed that it is), I disagree with
your arguments that there is "nothing wrong or unfixable about Jpeg". Our eyes
are accustomed to poor web Jpeg quality but I think if something better comes
along people will see it.

Also, given Opera and Chrome already support WebP, if Mozilla throws its
weight behind it, I think Safari and IE will oblige in short order. The
browser landscape is very different from the days of early PNG, and adoption
_will_ be quick. Just look at how quickly Microsoft transforms into the "#1"
advocate of HTML5.

~~~
jrmuizel
My position isn't that there's "nothing wrong or unfixable about Jpeg" at all.
There's lots wrong and fixable with JPEG. My problem with WebP is that it
currently doesn't fix enough of the problems that JPEG has and that if we
adopt it right now we might end up with another format that still has problems
and will have to replace WebP with yet another format that fixes those
problems later. JPEG took 6 years to standardize and has lasted for nearly 20,
this suggests that we might not want to rush to commit to a 8 month old image
format with a bitstream that was frozen the moment it became public.

As for support in other browsers, WebM is supported by Opera, Chrome and
Firefox, plus it solves problem of being a royalty-free modern video codec and
neither Safari nor IE have obliged in short order. What do you think that WebP
brings that will make adoption happen faster than WebM?

~~~
HardyLeung
I think let's just agree that Jpeg has a lot of problems and we'd like to seek
the best replacement. Obviously high-compression rate is important or else
everything should migrate to PNG, but the current Jpeg tradeoff between
quality and size is not just not very good. Also interestingly, there seems to
be a very wide spectrum of Jpeg lib quality from decent to very bad, and I
found out about that while experimenting with WebP.

WebP is different from WebM in that there are IP issues. I think WebP is more
like SVG/Canvas in that vendors don't see any "hurt" in supporting them once
there is enough momentum behind. Of course, your point about making sure that
we don't want to support any half-baked image format. I think WebP is beyond
half-baked, and an initial pledge of experimental support -- instead of an
outright rejection which seems to be tone -- doesn't hurt.

------
kevingadd
I've yet to see a compelling argument for why I should want a browser with
WebP support. Unless images start out lossless, and then are encoded into WebP
directly, all I'll ever get out of WebP is smaller images that have more
encoder artifacts - and I don't want that. I've got plenty of bandwidth; I'd
rather download images in their original JPEG or PNG formats, especially if
that means I can then open them up in any image editor or viewer on my
computer, instead of having to install some special (and likely buggy) new
WebP viewer/converter.

I think if WebP offered useful features JPEG doesn't, like alpha channel
support or support for higher bit depths or useful new metadata, that'd at
least justify it, and people would be creating new demos that showed off the
technology. We saw this with the uptake of support for PNG after people
started showing how PNG's support for alpha transparency made it possible to
do interesting things that you couldn't with JPEG/GIF. WebP has no such
compelling feature.

~~~
ansy
We don't have plenty of bandwidth with mobile applications. It's quite common
for even basic sites to slow to a crawl on 3G. Even with LTE just around the
corner, richer multimedia at higher resolutions will partially offset those
gains.

Note that according to Nielsen's Law bandwidth growth rate, while sill
exponential, is slower than Moore's Law (transistor count) and Kryder's Law
(disk space), so we will be increasingly bandwidth limited as time continues
[1]. For an example just look at SSD hard drives. To overcome bandwidth
limitations the best SSDs now have whole ARM based computers in them to
compress data on the fly, reorder operations on the fly, and run its own
garbage collection programs just to save from going over the already very fast
SATA bus which the latest drives fully saturate.

[1] <http://en.wikipedia.org/wiki/Nielsen%27s_Law#Contributions>

~~~
ericd
SATA is saturated because the increase in performance between platter disks
and SSDs is a big discontinuity in what had been a relatively slow but
steadily rising curve in the max sequential speed of a disk. Right now SATA is
playing catchup, and has had two fairly major iterations in a much shorter
cycle than what used to be the case. SATA 6gbps isn't saturated by even the
Vertex 3.

Mobile bandwidth is a problem for completely different reasons - I wouldn't
equate them.

------
dsl
Google is essentially comparing WebP to JPEG right now like you would compare
PDF to plain-text. They have a proof of concept ("look, the text appears on
the screen!") that has a smaller file size but lacks any actual features. My
concern is that once they implement all the features required of a mature
image format (alpha, color modes, etc), size will be on par with another
existing format.

~~~
asadotzler
My concern is that I don't see a roadmap for the missing features and there
are existing next-gen codecs that already perform better than JPEG and do have
those features.

------
oconnor0
It's important to note that this is a rejection of WebP, as it currently
stands, not a forever rejection.

~~~
ZeroGravitas
Google announced more features for WebP at Google I/O (including lossless and
animation amongst others). I've not seen any Mozillan response to that as yet.

~~~
asadotzler
"Google said they'd give everyone ponies! Respond!!!"

Please point me to the roadmap document for WebP that shows which features
Google intends to implement and the schedules (even rough guesses) for getting
those features implemented. Without that, I don't see what there is to respond
to.

~~~
ZeroGravitas
This mailing list post (and the Google IO video linked within it) is probably
the closest thing to a roadmap that exists, though it's vague on timelines:

[https://groups.google.com/a/webmproject.org/group/webp-
discu...](https://groups.google.com/a/webmproject.org/group/webp-
discuss/msg/7e72105a4e1d582e)

I personally am relatively comfortable with Google's throw it at the wall and
see what sticks approach. I understand that others aren't but hope that
Mozilla engages constructively so that WebP improves in a measurable way even
if you/they have no intention of adopting it.

The "we need it to sit in ISO committees for 10 years before we can even think
about implementing it" approach reminds me too much of the bureaucratic
process trolling that Microsoft are so good at. It's good trolling because
it's also a natural response and vaguely professional sounding, while still
probably being either non-productive or actively detrimental to the technical
outcome.

Note that from my amateur readings (notably
<http://sites.google.com/site/dlimagecomp/ms-ssim-results>) JPEG-XR seems to
be suffering from the exact problems that WebP is alleged to have (i.e. being
designed for PSNR to the point that it's actually worse than venerable JPEG in
SSIM and subjective tests). JPEG-2000 seems to have the same issue to a lesser
degree. If Mozilla can bring some automated metrics to bear on this (and any
parallel JPEG improvements), and metrics seems to be one of your/their
strengths, then I'd be very happy, since it seems the JPEG-XR and 2000 teams
may have been misled by their own metrics. Having multiple eyes on the
problem, particularly those looking to find fault from the outside, would be
great regardless of whether the result is WebP being improved or scrapped.

------
wladimir
WebP should implement alpha transparency. That was in their promise but they
never did it. That'd make it a jpeg-killer for me. A lossy image format that
supports alpha transparency would be so great.

~~~
dchest
Alpha support is in the repo, marked as experimental:
<http://review.webmproject.org/gitweb?p=libwebp.git>.

~~~
wladimir
Thanks! I'll give it a try.

IMO the WebP project should focus more on this. It's a big thing, also on the
web, to have a compact image format that supports partial transparency.

It blows away "simply using less bandwidth for photos" as an advantage, as it
makes entirely new things possible.

------
istvanp
Striving for a lower file size is inherently a good thing, but as disk space
is becoming cheaper and cheaper and it's not as important anymore. Judging
from the comparison gallery at
<http://code.google.com/speed/webp/gallery.html>, it's not very impressing.
The result is much more blocky and there is significant loss in detail in
detail-concentrated areas.

Case in point: the first image of a landscape has two major noticeable
artifacts: the shadow of the mountain (mid-right) reveals the blocky
compression of WebP. Second, the compression algorithm tends to smooth out a
lot of detail. Observe how the vegetation gets mushed out. The clouds as well
(mostly on the top left).

Great for video, not so much for images (from the gallery above anyway). I
would like to see a better comparison with WebP vs JPEG but compressed to
about the same file size and with a RAW source (to remove any compression
bias).

------
Aloisius
Why not JPEG XR? It supports transparency, lossy and lossless compression, 16
bit channels, color management and has better compression.

Is it really just because it was made by Microsoft?

~~~
ZeroGravitas
You mention that it has better compression, which Microsoft certainly claims
for it, but can you find any comparison that shows XR as better than standard
JPEG when measured with SSIM rather than PSNR? Or subjective human tests[1]?
There's quite a few showing it losing to JPEG. Surely they can't all have
messed up their testing methodology, though creating and standardising a
purpose built photo codec in 2009 that's worse in quality at many common rates
than JPEG seems somewhat unbelievable too.

1: "the visual performance of HDPhoto showed notable deficits, both in
subjective and objective tests."

from _Visual Quality Improvement Techniques of HDPhoto/JPEG-XR_ by T Richter

<http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04712398>

------
rudiger
Is "WONFTIX" a quirky Mozilla thing, or a typo of "WONTFIX"?

~~~
sid0
A typo.

