Slashdot Mirror
Mozilla Rejects WebP Image Format, Google Adds It
icebraining writes with a link to Ars Technica's look at the recent rejection of WebP by Mozilla Developer Joe Drew."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. (...) 'As the WebP image format exists currently, I won't accept a patch for it. If and when that changes, I'll happily re-evaluate my decision!' wrote Mozilla developer Joe Drew in a Bugzilla comment.'" However, as the article explains, Google sees enough value in WebP to add it as a supported image format for Picasa.
Why do we need yet another image format?
New file format's can't cure something that user education requires.
That mere fact that I am reading this article indicates that WebP has enough momentum to potentially be useful. The fact that other browser(s) are adding support is even more relevant. So the real question I believe is what wouldn't they add it? It's not costing anything, and (apparently) it's already been developed. So what's the issue?!
It is somewhat interesting to see an image format brought to the table without something basic like support for EXIF storage of some kind, or some feature(however crudely hacked on) that makes it clearly superior to JPEG(like an Alpha channel).
I can understand that somebody the size of Google probably gets real worked up about how to shove more images through slightly less bandwidth; but that actually seems like kind of a niche concern: For icon/branding/graphic design purposes, much of the heavy lifting is done by lossless(for clean, non-crunchy look); but small because of limited color palettes, broad areas of flat color, etc. images. That's mostly GIF and PNG, with some Flash and SVG.
For everyone from people who barely care to people who care how it will look as an 8*10 or a desktop background, you have JPEGs of various sizes and compression levels. On the low end, people will put up with some seriously grain-tastic shit, so long as it loads fast. Anybody who is too good for JPEG entirely is probably either slamming around some fancy print-ready flavor of TIFF, or storing whatever flavor of RAW their preferred camera back spits out.
I'm just not seeing the under-served niche here.
I won't accept a patch for it. If and when that changes, I'll happily re-evaluate my decision!"
Quality community driven, bottom up open source software at work!
Picasa? I would think the stronger indicator of support would be Chrome, but then again, Google's schizophrenic position on codec support ("We're rejecting H.264 video in the name of openness! Now enjoy the bundled Adobe Flash plugin and MP3/AAC playback.") makes them difficult to gauge.
Currently, it only supports a subset of the features that JPEG has. It lacks support for any color representation other than 4:2:0 YCrCb. JPEG supports 4:4:4 as well as other color representations like CMYK. WebP also seems to lack support for EXIF data and ICC color profiles, both of which have be come quite important for photography. Further, it has yet to include any features missing from JPEG like alpha channel support.
[...]
Every image format that becomes “part of the Web platform” exacts a cost for all time: all clients have to support that format forever, and there's also a cost for authors having to choose which format is best for them. This cost is no less for WebP than any other format because progressive decoding requires using a separate library instead of reusing the existing WebM decoder. This gives additional security risk but also eliminates much of the benefit of having bitstream compatibility with WebM. It makes me wonder, why not just change the bitstream so that it's more suitable for a still image codec?
WebP, by Jeff Muizelaar.
There aint no pancake so thin it doesn't have two sides.
No it is not dumb. Other than bloat there are support and security considerations. If it doesn't improve the status quo significantly why would you want to add work to already overloaded developers? Any code new code path can potentially add an exponential maintenance burden, slowing down future development. If it becomes an important format then the maintainer who rejected the patch has stated he is willing to re-evaluate letting the patch in. You really only ever want code in a project that you know the developers care about and are going to watch as well as have the knowledge to fix if a vulnerability is found.
If webp supported alpha transparency it would be useful. png is a lossless format and therefore much bulkier. A png is normally 5 times bigger than jpg image. But jpg doesn't support transparency
As author of the Mozilla WebP patch, I can confirm that this was originally true. However, due to various shortcomings in design, WebP split off into its own codec library.
How about baseing such as decision on considering what users want / need / might find useful, rather than some developers opinion of whether the technology has merit. Failing all that, because it gives users and web content creators an open source alternative choice?
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
PNG is lossless
More specifically it's a lossless representation of a single layer RGB image.
better for photos then JPEG.
For display of photos on the web the huge filesize advantages of JPEG outweigh the minor reduction in quality.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You mean like HD-DVD vs BluRay?
1) We know that JPEG 2000 (part 1) is most likely truly freely licensable. It was designed this way, and has been around for many years and used by deep pocketed companies for digital cinema, this I suspect any submarine patents would have surfaces by now. I can't say the same for WebP, WebM, or even H.264.
2) JPEG 2000 can have whatever color components you want. If you want a component to be an alpha channel, that is great, do it.
3) JPEG 2000 was developed by and international standards organization, so you know a lot of eyes saw the specification during development to ensure it is a well defined standard.
4) JPEG 2000 has a lossless option.
This article is about WebP, not WebM. Firefox does very much support WebM, just as do Chrome, Opera, Safari and IE (these last two browser require the WebM codecs to be installed, all the other just work). And YouTube is serving WebM video (among other formats).
There's a hidden treasure in Python 3.x: __prepare__()
WebP has a reference implementation whose license is compatible with free software licenses. JPEG XR, on the other hand, has patents licensed under terms that do "not provide the freedom that the GPL requires" according to the Software Freedom Law Center. And the copyright license of its reference implementation, the HD Photo Device Porting Kit, is not compatible with the GPL or any other copyleft license. Therefore, a JPEG XR decoder and GPL code cannot be combined to form one larger program. See Wikipedia:JPEG XR#Licensing and Wikipedia:Microsoft Open Specification Promise#Scope limitation.
I want a new image format.
I want alpha, I want CMYK or whatever colourspace. I want exif or whatever metadata.
But more than anything I want it to support both lossy and lossless algorithms so we can finally see an end to people using jpg for everything, including hard contrast logos.
It would just take a checkbox on the save dialog with some wording to encourage lossless where appropriate.
This signature intentionally left blank
I'm by no means an image expert, so read this as a question and not a suggestion: why isn't this implemented as a compression format for TIFFs? My understanding is that a TIFF is basically a bunch of metadata wrapped around a chunk of image data. I mean, look at the output of tiffinfo sometimes. I have a hard time believing WebP could require metadata than TIFF already supports, but you could add new private fields if it does. Given that you already have a (to my eyes) perfectly usable container, it seems like a waste not to use it.
Dewey, what part of this looks like authorities should be involved?
pretty much all his argument could have been used on why NOT to use Mozilla when it was new.
Something that's being overlooked here is size. WebP is about half the size of an equivalent Jpg.
Of course, ti really won't go too fer until the add the alpha ability.
After which I expect it to make some quick jumps on the way to becoming the standard.
For no other reason then every cloud based storage is going to want users to use it.
I have 40+Gigs of Jpgs. We aren't even very active with the picture. Some people know seem to be constantly taking picture, so I'm sure there have 100's of Gigs worth of Jpgs. The value add of cutting the image size in half is huge. Not just for storage, but for transferring from smart phones.
It also occurs to me that cutting the image size in half would be desirable form telco that support smart phones on their systems.
The Kruger Dunning explains most post on
Yes, putting in systems that make it more open, available to every one, and make the web use a better experience is exactly the same as what MS did when it create specific ways where there proprietary formats were used and then developers had to use their tools~
Yes, we should create a process for anything new to be adopted on the web, that would work so well~
The Kruger Dunning explains most post on