Weekly Edition
Return to the Announcements page
| |||||||||||||
Mozilla rejects WebP image format, Google adds it to Picasa (ars technica)
Ars technica looks
at WebP adoption. "Building mainstream support for a new media
format is challenging, especially when the advantages are ambiguous. WebM
was attractive to some browser vendors because its royalty-free license
arguably solved a real-world problem. According to critics, the advantages
of WebP are illusory and don't offer sufficient advantages over JPEG to
justify adoption of the new format. Aside from Google—which
introduced official support for WebP in Chrome 12—Opera is the only
other browser that natively supports the format. Despite the ease with
which it can be supported, other browser vendors are reluctant to endorse
the format and make it a permanent part of the Web landscape."
(Log in to post comments)
Mozilla rejects WebP image format, Google adds it to Picasa (ars technica) Posted May 24, 2011 21:26 UTC (Tue) by Hausvib6 (guest, #70606) [Link]
Mozilla has taken the right decision, adding arbitrary image format, especially unproven ones, in its product may cause support headache. Google can always fork Firefox if they don't like Mozilla's decision.
Finish JPEG support first, perhaps Posted May 24, 2011 22:15 UTC (Tue) by pboddie (subscriber, #50784) [Link] When I discovered that Firefox didn't observe EXIF information about image orientation, I found this longstanding bug which coincidentally acquired another observer yesterday. The tools I use actually rotate images rather than changing the orientation data, but other tools do the latter. Apparently it's a lot of re-architecture work to fix this, but I almost got tempted to get a Mozilla toolchain up and running again at one point, just to see something happen with what one might think is a relatively trivial feature request.
Finish JPEG support first, perhaps Posted May 25, 2011 2:36 UTC (Wed) by joedrew (guest, #828) [Link] As the module owner of Mozilla's imagelib (and, incidentally, the person who WONTFIXed the WebP bug), I'd love to have someone contribute EXIF orientation support. I'd be glad to give you any help you might need. I'm joe on Mozilla irc, channel #gfx :)
Finish JPEG support first, perhaps Posted May 25, 2011 10:20 UTC (Wed) by pboddie (subscriber, #50784) [Link]
Well, at least I have faster hardware than I first used to build various Mozilla applications, so maybe I'll take a look at least. :-)
Google's change of plan Posted May 24, 2011 22:29 UTC (Tue) by bawjaws (guest, #56952) [Link]
The Google team behind WebP appear to have changed tack. Originally they seemed to be keeping strict compatability with a single WebM frame and seeing how far that got them. And at least Opera found a use for that version.
Perhaps based on Mozilla's feedback though they seem to have set about building a comprehensive web image format capable of replacing JPEG, GIF, PNG and APNG amongst others by adding tiling, alpha, lossless, metadata etc.
The timing of this article is poor, since it leads with Mozilla's rejection of the first version. I'd be more interested to hear their response to the newly revealed plans, only some of which have actually been implemented.
Google's change of plan Posted May 25, 2011 1:43 UTC (Wed) by elanthis (guest, #6227) [Link]
But why do we need such a format? Do one thing, and do it well. e.g., if we already have PNG, we don't need a WebP that does the same things.
A lossy format with translucency is interesting, a lossy format with better compression is interesting, but that's about it.
At best I could see a PNG-like format that uses a more modern compression scheme (XZ or something similar), but that's it.
I think the only really interesting format that could exist that doesn't would be something akin to DDS, but open. That really has little use for the Web in general, but would be great for WebGL games.
Google's change of plan Posted May 25, 2011 4:15 UTC (Wed) by roc (subscriber, #30627) [Link]
A lossy format with much better compression would be a good thing. If we're going to take a new format, it should support translucency, EXIF and other obvious features as well as offering the best compression we can get with state-of-the-art patent-unencumbered technology. That would be worth having.
The first release of WebP wasn't that, but maybe it's evolving into that. As noted above, this LWN article, and the Ars Technica article it's based on, are untimely since Jeff's "rejection" was directed at the first version of WebP and WebP has evolved since then.
Google's change of plan Posted May 25, 2011 8:55 UTC (Wed) by bawjaws (guest, #56952) [Link]
> Why do we need such a format?
Well the obvious gaps at the moment are:
* Lossless photos need to be done in PNG, which is excessive in size for that type of content
If WebP can hit enough of these then it's got a real chance of getting the initial traction it needs. Imagine Wikipedia for example moving to lossless WebP for storing master copies of images and converting from that to a lossy WebP image for standard use and JPEG, PNG or GIF (as appropriate) for legacy browsers.
Google's change of plan Posted May 25, 2011 9:53 UTC (Wed) by marcH (subscriber, #57642) [Link]
> * Lossless photos need to be done in PNG, which is excessive in size for that type of content
Is this only because PNG compression sucks for photos?
Do you know of any good lossless compression for photos?
Google's change of plan Posted May 25, 2011 10:45 UTC (Wed) by bawjaws (guest, #56952) [Link]
I believe both JPEG-XR and JPEG-2000 have lossless modes designed for photo use cases so it's not exclusive to WebP (they also both do alpha transparency). In fact I don't know if Google are even at the planning stage for how to add it, but it has been announced as a feature goal.
How good they all are (or will be in WebP) in compression terms I don't know but I'd guess they're all much better than PNG for anything vaguely photorealistic. Whether having to add lossless to an existing video frame format leads to any terrible compromises compared with built in from day one would be interesting to see.
Lossless compression Posted May 25, 2011 11:12 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
As an example:
JPEG works by doing a DCT on blocks of the image and then truncating the result for each block. If you don't truncate the results are lossless, because with the untruncated values you can inverse DCT and get back the original blocks. The same applies to most lossy compression algorithms, they have a step where they deliberately throw away the least significant data, if you "skip" that step the output is far larger but it's now lossless. Technically of course it won't be as simple as commenting out some code, if you have 73 bits of lossless transform data and there's a field which goes up to 64 bits, you need a new format to not throw away at least 9 bits of your precious image data. In the case of the iDCT you also need to specify the exact rules so that "off-by-one" errors don't occur. I'm sure there are other tricky bits I've forgotten.
There are purpose made lossless photographic compression algorithms with quite excellent compression performance on real pictures - it's an ongoing area of research - but some are very expensive (e.g. 14 hours to compress a 1MP image on a fast modern PC) and thus not suitable for most purposes we care about.
Google's change of plan Posted May 25, 2011 15:23 UTC (Wed) by __alex (subscriber, #38036) [Link]
Why not extend the WebM format and browser support to meet all those use cases? It uses Matroska so surely there's no reason to only put VP8 data in it for lossless graphics too?
Google's change of plan Posted May 25, 2011 17:22 UTC (Wed) by nicooo (guest, #69134) [Link]
> * Lossless photos need to be done in PNG, which is excessive in size for that type of content
JPEG 2000/XR
> * Photos with alpha need to be done in PNG, which again is excessive in size
> * Animation needs to be done in GIF or APNG, which are limited in palette/alpha and not widely supported respectively
> * JPG falls apart at low bitrates and sucks for gradients or other page design elements (even apart from the lack of alpha channel)
> * illustrations (and other things that are somewhere in the spectrum between photos and simple line graphics e.g the Google logo or scanned text documents) fall between the sweet spots of JPG and PNG
Google's change of plan Posted May 25, 2011 21:29 UTC (Wed) by ikm (subscriber, #493) [Link]
> A lossy format with translucency is interesting
It's not just interesting, it's outright MISSING now. So right now you have to resort to PNG if you have images with alpha.
Google's change of plan Posted May 25, 2011 3:04 UTC (Wed) by Hausvib6 (guest, #70606) [Link]
So... to display a WebP image in WebM capable browser, can I create a single frame video in WebM and put it into <video> tag?
Google's change of plan Posted May 25, 2011 8:35 UTC (Wed) by bawjaws (guest, #56952) [Link]
Yes. Here's a javascript shim that does exactly that to add support in Firefox and earlier versions of Opera and Chrome:
http://antimatter15.github.com/weppy/demo.html
It's a hack, but it works for basic image display (but not for CSS backgrounds, for example).
Google's change of plan Posted May 25, 2011 11:45 UTC (Wed) by Hausvib6 (guest, #70606) [Link]
Amazing, so WebP is supported by all WebM-capable browser. This workaround can provide temporary solution until Mozilla agree to add WebP image support while hoping that any change to the WebP data format will be harmless.
Google's change of plan Posted May 25, 2011 16:44 UTC (Wed) by bronson (subscriber, #4806) [Link]
Another workaround is for Google to fix the deficiencies that the Mozilla team found. Add EXIF, ICC, and alpha support, make compression a little better, and Moz would likely merge it themselves.
I'd much rather see work go into improving WebP than into the sort of hacks that made a mess of the web in the 90s.
Google's change of plan Posted May 29, 2011 16:34 UTC (Sun) by agajan (subscriber, #7859) [Link]
This article about Google's plans for WebP is dated May 25, 2011.
|
|||||||||||||