New WebP image format from Google will be going into Chrome with claims of 40% smaller files compared to JPEG at same quality. CNet appears to have preempted the official announcement, so tech specs are not out yet, but it appears to be derived from WebM. http://news.cnet.com/8301-30685_3-20018146-264.html

I heard 75%. If Firefox doesn't implement this immediately I will start using Opera.

http://x264dev.multimedia.cx/?p=541 is an interesting read...

So... looking at our release rate, can I hope we get this in Firefox 4? :)

No, we haven't even decided if we want to take it for Firefox, period. It's a very new decoder, and hasn't been evaluated.

Evaluation aside, I have a basic patch ready and will post later today after I have some time to test (there isn't even a Windows encoder yet, and not even Google has published any webp files (just webp converted to png). It's pretty simple since most of the decoding is performed by libvpx, which is already included for WebM support.

Here is an implementation of WebP. I believe it is fully functional, but if there are problems, please let me know. Some notes: - This will not compile using --disable-libxul due to the dependency on libvpx. If somebody could help me with the best way to add the necessary linking, it would be appreciated. - This patch does not have progressive decoding because I'm not sure whether libvpx supports incomplete data (anybody know?) - Most of the code is my own, but it was based on the BMP decoder and includes a couple functions from the reference WebP decoder. I'm not sure whether I denoted this properly in the license block. - Said functions involve the YUV to RGB colorspace conversion. I'm assuming that there's a more global way to do this that would entail hardware acceleration. Should YUV be supported directly as a gfxASurface ImageFormat? How is it done for WebM? It's been a while since I've done anything with libpr0n, so comments, questions, etc. welcome.

There is optimized YUV to RGB conversion code in gfx/ycbcr that might prove useful.

Yes, that simplifies things greatly.

Haven't looked at it closely at all, but I thought I'd document some things I noticed while skimming: >eDecoderType_icon = 5, >+#ifdef MOZ_WEBM >+ eDecoderType_webp = 6, >+ eDecoderType_unknown = 7 >+#else > eDecoderType_unknown = 6 >+#endif I don't want the value of eDecoderType_unknown to vary like this. Just define it to 100 or something. >+ vpx_codec_destroy(&mDec); This should happen in the destructor, because FinishInternal() is not guaranteed to be called.

And what?

libwebp is now in Chrome and Opera for Firefox, the question to answer is: should it use libvpx or libwebp? libvpx has the advantage that the code is already there libwebp brings 2 features that are not in libvpx: - incremental decoding (as of libwebp-0.1.2 released yesterday) and - fancy upsampling which improves decoding for strong edges. - Before: http://www.gstatic.com/webp/blog/red_detail2_prev.png - After: http://www.gstatic.com/webp/blog/red_detail2_new.png Aaron, what's your preference?

libwebp would be my preference since tying image support to a movie format, which may or may not be built, is not optimal. It would be good to have those new features, particularly incremental decoding, which is the norm from other image formats. Fancy upsampling support may be more difficult, as I don't know of decoder-specific upsampling support in Firefox. Of course, while I am happy to implement the glue code, I am not in charge of the decision to include WebP support in Firefox.

Ok, thanks for the note. Do you mind creating a patch to include WebP and let's see if it gets accepted? The git repository is at http://www.webmproject.org/code/#webp-repositories

Comment on attachment 480498 [details] [diff] [review] WebP implementation Let's put a real name into the feedback flag to increase the chance of getting feedback :)

It this patch updated to latest libwebp-0.1.2 ?

patch with libwebp-0.1.2 support in progress, I hope by end of next week

(In reply to comment #19) > patch with libwebp-0.1.2 support in progress, I hope by end of next week I actually have this done; will post tomorrow.

I can help you in initial code-review. I started working on it day back and have following structure for the changes. The code is little far from finish state and would like to support you on this bug-issue. 1.) libwebp-0.1.2 contents rolling out in new folder 'modules/libimg/webp/' 2.) High level hooks required for WebP in Image Raster code (your original bug-patch#600919. Here I added WebP support (unconditionally) without wrapping under WEBM compile flag. 3.) nsWEBPDecoder class (modules/libpr0n/decoders) with intrinsic virtual methods InitInternal(), WriteInternal() & FinishInternal() implemented. WriteInternal() should use the incremental decoding supported available in 'libwebp-0.1.2' 4.) WebP image tests for browser under 'modules/libpr0n/test/reftest/webp/*.webp'

(drive-by comment): please use spaces instead of tabs.

Aaron, I have uploaded reference implementation of nsWEBPDecoder that utilizes incremental decoding from WebP lib (ver 0.1.2). In case you have already implemented it, I can do high-level review w.r.t usage of WebP decoding APIs

Comment on attachment 480498 [details] [diff] [review] WebP implementation Right now I don't think we want to have WebP support. See http://muizelaar.blogspot.com/2011/04/webp.html for some of the reasons why.

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!

Bad choice, since WebP have superior quality compared to JPEG with the same file size. Just do some tests with XnView on PNGs to see that's true. Also how we want to replace old JPEG with new open format when we aren't open to new standards like Chrome or Opera for example.

I'd like to point out that there currently is no lossy RGBA image format on the web. People are forced to use PNG32 (if quantized PNGs don't offer enough colors) which is f-ing horrible for performance. Mozilla's own websites are a good example for this. E.g. the Jetpack, Prism, and Testpilot logos can be easily reduced by 80% if JNG (or a JNG-like) format is used. I've seen pages which had more than 1MB (>5MB in the worst case!) of bloat thanks to this awful PNG32 workaround. You guys killed JNG and now you don't want to support WebP. What's plan B? Ignoring this issue until everyone got a 1gb/s+ connection?

(In reply to comment #27) > 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! Explanation please? What is the actual argument against WebP?

Please see the link in comment 26 for a full explanation.

I think Joe was pretty clear in the blog post in comment #26. It's a well reasoned and compelling argument. That said, he didn't say he would NEVER include WebP just that it's not ready now. Just because it's a new "fancy" image format doesn't mean it should be included in Firefox.

It's illogical... WebP have BETTER quality than JPEG with the same file size WebP is SMALLER than JPEG with the same quality This post on blog didn't have any real tests. It's ONLY based on opinions.

(In reply to comment #33) > This post on blog didn't have any real tests. It's ONLY based on opinions. No, but it did have real facts, which you clearly ignored given the two points you provided in your comment. If you aren't going to provide new information, please don't bother to comment (per https://bugzilla.mozilla.org/page.cgi?id=etiquette.html).

I also provide real facts based on my tests with PNGs in XnView and results were like I stated in comment #28 and #33.

I normally don't jump in on things like this, but I'm going to now. http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/ "it’s a compression schema that does seem to outperform jpg." http://gvsigmobileonopenmoko.wordpress.com/2010/12/19/googles-webp-vs-jpeg-a-more-comprehensive-test/ "WebP format is able to improve JPEG’s performance by about 40% in certain cases." I couldn't find any sites that were screaming that webp sucks and shouldn't be adopted. Maybe I didn't look hard enough?

While I do not usually post on bugs like this, this time I think there is a reason. Even if the standard is not yet well developed, that does not mean it should not be supported. After all Mozilla frequently supports standards that aren't already ready for addition since adding and using them are often the best methods to pick out holes and help get them files. Having the second most popular browser and is derivatives implementing this would give the format a chance to adapt and grow. And if it does not do so then it can always be disabled and moved later, as was done with XBM. Lack of support can kill a standard dead - should this standard be killed off or given a chance to grow?

Brian, Ryan, and Virtual_ManPL where do you think bar for including support for an image format should be? We certainly can't add support for every image format that gives better compression than JPEG.

(In reply to comment #38) > Brian, Ryan, and Virtual_ManPL where do you think bar for including support for > an image format should be? We certainly can't add support for every image > format that gives better compression than JPEG. What might Opera's motivation ave been, to support WebP since it's recently released Opera 11.10? Aren't they in quite an equal situation like you Mozilla folks and are trading pros against cons supplying such a format? And they decided to supply it. It would be interesting to know, WHY they've decided to implement and supply WebP at the end of such a weighing process and what are their reasons to do so and to do so relatively early compared to the rest of the browser makers... Might it really be just the reason to be able to say "First!"? Or might there additionally exist some more other and deeper convincing reasons Opera sees for implementing and supplying WebP in their web browser?

(In reply to comment #38) Additionally question: Why has got the popular image editing software for the Mac, Pixelmator, implemented WebP since 10/2010 and is fostering it? Pixelmator Blog entry Wednesday, 6 October 2010: Pixelmator 1.6.2 Adds WebP Support http://www.pixelmator.com/weblog/2010/10/06/pixelmator-1-6-2-adds-webp-support/ Why are they (Pixelmator, Opera, etc.) doing this and are empracing/absorbing WebP? Just another 'me too' but worthless image format? Or does WebP have potential in many ways to evolve, to consolidate, to persuade and therefore to appreciable disperse?

Most of these statements toward 'WebP is superior to JPEG' can also be true regarding ISO/15444 JPEG2000, but after 10 years everyone but Safari@Mac still ignores it. (Submarine patent is not the problem as we are implementing WebM which may also be threatened.) WebP is not even a standardized format. Supporting developer's decision.

>We certainly can't add support for every image >format that gives better compression than JPEG. I for one would be happy if you would support *one* lossy true color image format which supports alpha. I don't care if it's WebP or JNG. I would be even fine with splicing two inlined images in one SVGZ together, but due to some SVG spec quirk[1] this isn't[2] an option. [1] http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0103.html [2] http://i.imgur.com/eEB6e.png

When I visit www.getfirefox.com, I see the words "Made to make the Web a better place." I believe part of making the web a better place is support new technologies like WebM and WebP. With ISPs around the world capping bandwidth (including cell phone companies), high quality images that don't use up a lot of bandwidth would be a welcome thing for a lot of people. Heck, even people in developing countries that don't have high speed connections would welcome high quality images that don't take an hour to load. Seriously, who is it going to hurt by supporting WebP? Firefox supports APNG when no other browser does (except Opera according to http://en.wikipedia.org/wiki/APNG) and who uses APNG? =)

(In reply to comment #42) > I for one would be happy if you would support *one* lossy true color image > format which supports alpha. > > I don't care if it's WebP or JNG. WebP doesn't support alpha.

(In reply to comment #44) > (In reply to comment #42) > > I for one would be happy if you would support *one* lossy true color image > > format which supports alpha. > > > > I don't care if it's WebP or JNG. > > WebP doesn't support alpha. ...yet. But as said, it's being experimented with: https://review.webmproject.org/#change,2185

JNG was the obvious route, but Mozilla killed it along with MNG. We were told to use Flash instead. *shrug* The next thing was SVG, but that masking issue will probably take years until it's sorted out. I mean, it took over 10 years to identify this problem and right now there are approximately 2 people who care about it. WebP is the just the closest available lossy RGBA thing. If this chance is missed, things will be delayed even further - again. [Seriously, even IE would have supported JNG by now if you guys hadn't killed it back then. It's such a simple format. If you got the code for reading JPG and PNG, you're basically already there. There is just some glue missing.] Well, you can use something like JNG today, but it isn't even remotely practical: 1. Create something which splits a PNG32 into JPG + PNG or JPG + JPG. On demand would be nice. 2. Send this as gzipped b64 mxhr thing or as binary blob. 3. Take it apart. 4. Put it back together via an off-screen canvas. 5. toDataURL -> localStorage As you can probably tell this is needlessly complicated. Even though I skipped some steps. Oh, and there is that ~5mb limit, too. So... yea... please implement WebP support. Otherwise everyone will continue to use PNG32 images for this (which are typically 4-5 times bigger).

> WebP is not even a standardized format. Going by this logic HTML5 should also be not supported since it's still a draft and the spec can change, right?

Anyway, can someone provide a good reason why implementing support for one additional image format is a bad thing? Because it doesn't support some ICC color profiles or colorspaces, or doesn't have an alpha channel (yet)? Most of the time I couldn't care less about these things. Also, people here seem to think "implementing WebP = dropping JPEG" or something. Even if the format doesn't have wide support or many features there is no reason to not add another format that has advantages in some areas and disadvanges in others. People will use which format better suit their needs, and as I can see WebP provides better compression, and what actually counts for most users is the filesize. Most images on the web are buttons, logos, icons, screenshots and other images that don't need any other information than a plain bitmap, no matter how it's stored.

> Anyway, can someone provide a good reason why implementing support for one > additional image format is a bad thing? Sure. If the bar to accepting a new image format for the Web is as low as "better than all current image formats in some way", then we could end up adding lots of new image formats that each have their own advantages. Each of those formats would need to be supported by all consumers of Web content, forever --- bloat --- and would add complexity for Web authors trying to find the best format for their needs. It's better to take bigger steps and each time we add a new image format, make sure it's as good as we can make it at that point in time. Jeff's post suggests that WebP isn't there yet. bugzilla@kaioa.com: WebP doesn't support alpha. It really doesn't. Maybe one day --- maybe even soon --- it might, but it doesn't *now*. We can only evaluate an image format as it is. If WebP evolves into something better, it should certainly be reconsidered. For all the WebP fans here, please dissect Jeff's blog post and come up with rational responses, preferably on his blog on in mozilla.dev.platform, rather than just making advocacy statements. Thanks.

> Anyway, can someone provide a good reason why implementing support for one > additional image format is a bad thing? > > Because it doesn't support some ICC color profiles or colorspaces, or doesn't > have an alpha channel (yet)? Jeff might correct me, but I think an implicit argument in his blog post is: In general, Mozilla should use its weight to improve the web in the long term, even if doing so is unpopular in the short term. In this case, by not accepting WebP in its current form, we're putting pressure on its developers to improve it in the ways that we think are important. Once we accept the codec, we lose this leverage. You'll recall that we did something similar with video. By drawing a line in the sand against H.264, we provided its eventual challenger, WebM, with crucial momentum. If you go back and read the Slashdot comments, you'll see that this was pretty unpopular at the time, especially when all we had was Theora. But I think we're in a much better place for it now. Remember that even if we landed this patch tomorrow, it would still likely be years before this format saw wide adoption. The argument is that it's better to wait and throw our weight behind something we think moves the web forward, if and when that arrives.

Mozilla is on the second place after IE in web browsers usage on the world. In many countries is on first place. Chrome and Opera support WebP now. If Gecko browsers will support it, we will add pressure on M$ to also add support for it. So we will have about 25-50% smaller images size on the web. This will be a great advantage in mobile browsing, which is mainly shared by Opera Mobile/Mini which support WebP and add also Turbo. Don't forget that you guys killed many formats before. Supporting format which is under fast development should be your priority to not make the same similar mistakes like in the past, because not supporting it fast can be a sure kill.

(In reply to comment #51) > So we will have about 25-50% smaller images size on the web. We could have 20% smaller image sizes on the Web if people just used a better JPEG encoder, but no-one seems to care.

>WebP doesn't support alpha. I'm aware that WebP doesn't support alpha yet, but it's planned since day one. Since no other image format on the web fills this slot[1] this feature will be added. It's a kinda big deal, you see. Of course I'd be also fine with JNG (or a subset thereof which only supports 8bit/channel), but I know that this won't happen for political reasons. (There aren't any technical reasons for not supporting it.) >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! Note that "RESOLVED WONTFIX" tells us a different story. [1] http://kaioa.com/b/1011/jng_decision_matrix.svgz

I am a bit perplexed about the real reasons for not including support of WebP. Of course, there is ample debate on advantages or disadvantages, but for low bitrate encoding, it handily beats jpeg and jpeg2000. An excellent comparison, done with some different source materials is here: http://goldfishforthought.blogspot.com/2010/10/comparison-webp-jpeg-and-jpeg-xr.html and my own, very unscientific one is http://carlodaffara.conecta.it/a-small-webp-test/ The end result is that for medium/high bitrate WebP is on a par with Jpeg, for low bitrate it beats jpeg substantially. Now: the reasons for not including it in firefox are: - IPR issues? - not enough features? - not enough quality? As for Jeff's post, some of the comments already addressed some details (especially quality comparisons, or the 4:2:0 space); I would like to see what features WebP misses before it could be considered for adoption. As mentioned by bugzilla@kaioa, "RESOLVED WONTFIX" seem a more drastic choice...

(In reply to comment #52) > (In reply to comment #51) > > So we will have about 25-50% smaller images size on the web. > > We could have 20% smaller image sizes on the Web if people just used a better > JPEG encoder, but no-one seems to care. So you don't care, because someone don't care? Odd argument. But still we will have 30% more compression on WebP, which is far superior for mobile or even on PCs with slow connection. (In reply to comment #53) > Note that "RESOLVED WONTFIX" tells us a different story. I agree, this should stays as NEW, not WONTFIX...

(In reply to comment #55) > So you don't care, because someone don't care? Odd argument. > But still we will have 30% more compression on WebP, which is far superior for > mobile or even on PCs with slow connection. In theory? Yes. In practice? No. You seem to be making the assumption that every site out there will go out and convert their photos to WebP. Sites haven't even started converting to WebM on mass as of yet. So in reality it makes very little difference and will probably continue to make very little difference for a while. All Mozilla would do by fixing this bug is create an opportunity for adoption, but that really doesn't say everyone will take that opportunity. Google are the driving force behind WebP and if they truly believe in it and want Mozilla to adopt it, the onus is on them to meet a clear criteria that's been set by Mozilla. There appears to be four simple things that Mozilla require to adopt this format: EXIF data, Alpha transparency, lossless support and i8x8 intra compression (AFAICT). That's not a lot to ask for what Google are proposing to become the worlds new standardised image format. Thus it's simply a matter of Google putting their money and resources where there mouth is and in a much more proactive manner than they've done with WebM. If people would like to truly see this bug marked as fixed, I suggest the 'strong support' moves to WebP bug tracker so as that they can implement the features that Mozilla require to support it.

(In reply to comment #54) > Of course, there is ample debate on advantages or disadvantages, but for low > bitrate encoding, it handily beats jpeg and jpeg2000. An excellent comparison, > done with some different source materials is here: > http://goldfishforthought.blogspot.com/2010/10/comparison-webp-jpeg-and-jpeg-xr.html Your link states: > 6. WebP, in general, is okay, but I don't feel like the improvements are > enough. I'd expect a next-gen format to outperform JPEG across the board--not > just at very low compression levels or in specific images. > Now: the reasons for not including it in firefox are: > - IPR issues? Nope. We already ship VP8 which pretty much covers WebP in terms of IPR. > - not enough features? Yes. > - not enough quality? Yes, see above. > As mentioned by bugzilla@kaioa, "RESOLVED WONTFIX" seem a more drastic > choice... I think it would be silly to say we can never close a bug titled "Implement <X>" because <X> might change in the future to something that we do want to implement. Or maybe we implement <X> and then later someone reopens the bug because <X> has changed to something we don't implement. We don't want to implement what WebP is today. If it's much better tomorrow, file a new bug or possibly reopen this one.

(In reply to comment #55) > (In reply to comment #52) > > (In reply to comment #51) > > > So we will have about 25-50% smaller images size on the web. > > > > We could have 20% smaller image sizes on the Web if people just used a better > > JPEG encoder, but no-one seems to care. (I'm guessing about the 20% obviously, but no less so than people guessing 25-50% for WebP.) > So you don't care, because someone don't care? Odd argument. If Flickr and Facebook, which pump out enormous volumes of JPEGs and have more than enough resources to recode their images, don't care, who do you think will care? And if major sites don't care, the feature is going to be mostly ineffective. *me* caring is worthless, I don't serve JPEGs to anyone.

(In reply to comment #56) > if they truly believe > in it and want Mozilla to adopt it, the onus is on them to meet a clear > criteria that's been set by Mozilla. > > If people would like to truly see this bug marked as fixed, I suggest the > 'strong support' moves to WebP bug tracker so as that they can implement the > features that Mozilla require to support it. So it would be nice if someone from Mozilla devs give official feedback on WebP tracker/newsgroup and state what we want before implanting WebP to Mozilla products.

(In reply to comment #55) > (In reply to comment #53) > > Note that "RESOLVED WONTFIX" tells us a different story. > > I agree, this should stays as NEW, not WONTFIX... Maybe a new status could be created, such as "PENDING". It would better reflect what I understand to be the position expressed in comment 27. This could apply to all other experimental features bugs (like the period when WebSockets were disabled waiting for the protocol to be fixed). From what I understand of the situation, neither NEW nor RESOLVED+WONTFIX seem appropriate to describe the bug status.

(In reply to comment #59) > (In reply to comment #56) > > if they truly believe > > in it and want Mozilla to adopt it, the onus is on them to meet a clear > > criteria that's been set by Mozilla. > > > > If people would like to truly see this bug marked as fixed, I suggest the > > 'strong support' moves to WebP bug tracker so as that they can implement the > > features that Mozilla require to support it. > > So it would be nice if someone from Mozilla devs give official feedback on WebP > tracker/newsgroup and state what we want before implanting WebP to Mozilla > products. The blogpost link states what is required. I then summarised, given no one has corrected it, I guess it stands true > "There appears to be four simple things that Mozilla require to adopt this > format: EXIF data, Alpha transparency, lossless support and i8x8 intra > compression" The onus is now on Google to meet those requirements at which point this conversation can take place in a more appropriate manner.

Hi, Here's a technical argument why a better jpeg encoder won't solve all known problems. I made the following experiment: * take one logo from this page: https://wiki.mozilla.org/Firefox3.5/Logos this one, for instance: http://people.mozilla.com/~faaborg/files/shiretoko/firefoxIcon/firefox-48.png * flatten it with gimp, to remove the transparency * compress it with 'cwebp': cwebp logo_flatten.png -o logo.webp => result is just below 1k (note: source was 4889 bytes) * compress to the same size with jpeg8b, trying to match the size: cjpeg8b -optimize -outfile logo.jpg -quality 55 logo.ppm You can see all the resulting files on this page: https://picasaweb.google.com/pascal.massimino/WebpExperiment?feat=directlink (yes, Picasaweb now accepts direct WebP uploads). To get the original files, use the "Download" menu. You can get the WebP file back there. Note! what you see on this page is a jpeg-rendered version of the WebP file. Sending WebP directly to compatible-browsers is in the work. My point: you have less ringing on icons and thumbnails with WebP, more crispness. And even when the said WebP is back-transformed to JPEG for display purpose! Why? Because WebP uses 4x4 transform which may have some shortcomings, but also the big advantage of giving extra crisp details and less ringing. Please reproduce this experiment at will! (oh, and with alpha data compressed with zlib, using the experimental patch linked above, the total file size of the WebP would be: 1632 bytes. Alpha data counts for 560 bytes. You can compare this to the original 5640 bytes of 'firefox-48.png').

(In reply to comment #62) > Here's a technical argument why a better jpeg encoder won't solve all known > problems. You're arguing against a straw-man -- no one has made the point that you seem to be countering. Please re-read comment 52 & comment 58.

Its strange this is a WONTFIX. WebP reduces bandwidth by more than 50% with negligible decrease in quality. Please re-consider.

> WebP reduces bandwidth by more than 50% with negligible decrease in quality That's an exaggeration beyond what even Google has claimed. In any case, please read http://muizelaar.blogspot.com/2011/04/webp.html for Jeff & Joe's reasoning about this before objecting. (Jeff links to Google's actual study & results from that blog post, FWIW.)

FYI Opera started converting all images from JPEG to WebP in Turbo mode http://my.opera.com/chooseopera/blog/on-a-horse-opera-turbo-to-the-rescue

Please add support. The link that is used to justify *not* adding support is based upon an old version of the encoder.

The following image contains a cropped comparison, taken from "Diary of a x264 developer," which was cited by Joe Drew and Charles Bloom in their blogs as supporting evidence that WebP is inferior to JPEG. The author of the article states, "This seems rather embarrassing for libvpx. Personally I think VP8 looks by far the worst of the bunch, despite JPEG’s blocking. What’s going on here? VP8 certainly has better entropy coding than JPEG does (by far!). It has better intra prediction (JPEG has just DC prediction). How could VP8 look worse?" http://i.imgur.com/OAQXK.png It seems fairly obvious to me that this is false, and WebP actually contains a more accurate representation of the man pictured here. It looks better, and this isn't even debatable. In fact the man's eyes are completely lost in the JPEG version, and even his semblance to a human is questionable. He looks more like something you'd see in an old 8-bit video game for a popular game console in the 1980s. I think that there is simply bias in the mind's of various developers against WebP, even when the proof they themselves have provided contradicts them.

Further comparison: http://i.imgur.com/IGdpQ.jpg

(In reply to comment #68) At best you've refuted one point. This isn't an argument pivoting on one point, however...

(In reply to comment #70) The only other points besides quality that Joe seems to make on his blog are regarding: 1) Support for various color formats WebP supports current popular color formats, so I don't really see this as reasonable justification to deny WebP support in Firefox. That would be akin to someone suggesting that Firefox is not a valid modern web browser for public consumption simply because it doesn't support every single feature, and then some, that other browsers such as Chrome or Opera contain without the need for addons. And, I'm certain more features will be added to the format with time. 2) Google not having provided analysis with SSIM / Using recompressed JPEGs They've conducted another study with SSIM using uncompressed reference images from Kodak / Tecnick and other scientific caches of imagery for research purposes, e.g. Lenna. http://code.google.com/speed/webp/docs/webp_study.html 3) A lack of meta-data support: I feel this one is a definite oversight on their part. On the other hand, it is a blessing in a disguise, as meta-data has so far found more application as a tool to invade privacy than for any other legitimate use to date. Users have been stalked for uploading pictures with GPS locations that they were unaware were embedded in pictures for example. And, there are examples of women, who having provided a picture of their face have found that knowledgeable geeks have made use of, to perverted lengths, in order to retrieve previously cropped imagery from which the victim originally thought they were safe from exposing. 4) With his mention of JPEG-XR. Firefox's obviously continued support for formats such as PNG/JPG that lack XR features indicates their continued usefulness as web image formats. What WebP brings to the table is reduced bandwidth, hard disk space and graphics RAM consumption. If anything, support of WebP would be an environmentally beneficial choice.

(In reply to comment #71) > And, I'm certain more features will be added to the format with time. Yes, and we'll take them into account when we reevaluate WebP after they've been added. > 2) Google not having provided analysis with SSIM / Using recompressed JPEGs > > They've conducted another study with SSIM using uncompressed reference > images from Kodak / Tecnick and other scientific caches of imagery for > research purposes, e.g. Lenna. > > http://code.google.com/speed/webp/docs/webp_study.html That study is a week old, and post-dates all the arguments on this bug and elsewhere. It will definitely be part of the reevaluation. > 4) With his mention of JPEG-XR. > > Firefox's obviously continued support for formats such as PNG/JPG that lack > XR features indicates their continued usefulness as web image formats. Because there are billions of PNGs and JPEGs on the Web and the browser would be completely unusable if we stopped supporting them. That is not true for WebP. WebP is moving, and that's good, but it's not quite yet what we'd like to see (no alpha channel yet, for example). I'm sure we'll take another look at it soon. In the meantime, advocacy comments in this bug won't help.

WebP has been presented as an alternative to JPEG and JPEG doesn't support alpha channel either. The general consensus is that WebP is better than JPEG (there are exceptions like this http://x264dev.multimedia.cx/archives/541 but he has emotional problems with WebM/WebP). Also, Chrome does support WebP, Opera does support WebP, Chrome Frame for IE does support WebP... Mozilla Firefox is definitely stopping an advancement in web development, be aware of this. Fortunately, we still have essential features like "Personas".

Exactly. WebP is designed to replace JPEG, not all formats to create the best one. And in the end it's BETTER. Why we need alpha support or even EXIF data... ? ROTFL... Just say you just want to KILL this format and stop lying to us...

I can't understand the opposition to supporting WebP. Yes, there aren't many WebP images on the web but people aren't going to start making WebP images available until tools support them. (In reply to comment #72) > Because there are billions of PNGs and JPEGs on the Web Some of which Firefox can't display because it relies on an obsolete version of the IJG jpeg library (see https://bugzilla.mozilla.org/show_bug.cgi?id=597959 for details) > and the browser > would be completely unusable if we stopped supporting them. I don't recall anyone suggesting that Firefox stop supporting JPEG or PNG, just that it should _also_ support WebP.

A typical Mozilla.

(In reply to comment #74) > Just say you just want to KILL this format and stop lying to us... Gentlemen: to evil! Rob, please don't play with the tracking flags.

> And in the end it's BETTER. It would be even better with alpha channel. Worth the wait. And why can't you guys spend some of your energy lobbying Google for APNG support?

I'm confused. dev-doc-needed on a wont-fix bug?

I think sheppy was indicating that he wants to write up some documentation explaining why this was wontfix'ed. Obviously a lot of people want to know why we don't plan to implement WebP, in its current incarnation, in Firefox.

WebP support is listed as an "on hold", not "will not happen" feature on this page: https://wiki.mozilla.org/Features/Inbox Because of that, I marked it as dev-doc-needed. If it does ever happen, it will require documentation. That said, I hadn't noticed that it was won'tfixed. Since it is, I'll have to document why that's the case; presumably that will be done by summarizing http://bit.ly/fyd50C.

Maybe each item in Mozilla's list of feature requirements for WebP being included in Gecko should all be posted to WebP's bug tracker by someone with intimate knowledge of Mozilla's requirements.

From Jeff Muizlaar's blog (http://muizelaar.blogspot.com/2011/04/webp.html) we could see that the four features missing in WebP as far as Mozilla is concerned are: * Color spaces * Alpha channel * EXIF (or something similar) * ICC color profiles libwebp v0.1.3 was released on September 22nd, with support for RGB565, RGBA4444 & ARGB image colorspace(see https://groups.google.com/a/webmproject.org/group/webp-discuss/browse_frm/thread/4ad84ee86763484a). Both these features are still considered as experimental, but as far as I understand, they resolve the color spaces & alpha channel concerns. On somewhat related news, WebP support was added to Android 4.0 (http://developer.android.com/guide/appendix/media-formats.html)

It would seem that some of the "missing" things have been added: * Alpha channel & XMP metadata (http://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html) * ICC color profiles (https://groups.google.com/a/webmproject.org/group/webp-discuss/browse_thread/thread/4ab76cbde89e6ade/23512e5a1ed1dab0?lnk=raot&pli=1)

They've also added a lossless mode, support for animation and support for tiling(useful to webgl?) http://www.h-online.com/open/news/item/Google-enhances-WebP-to-take-on-PNG-1381681.html

While I'm ambivalent to whether WebP is implemented on the desktop, smartphone users would benefit from a version of Firefox with this format, as users aren't just looking for the best formats in terms of image quality and capabilities, but also on pragmatic issues such as speed and cost. Whether to make a smartphone implementation should be determined on if WebP can compress images significantly smaller than optimised JPEGs and PNGs (including PNG8 with https://github.com/pornel/improved-pngquant) of comparable quality at small file sizes. I've yet to see an independent and up-to-date/comprehensive study on the performance of WebP. This doesn't take away from criticism of WebP (http://muizelaar.blogspot.com/2011/04/webp.html). Rather, it's a different ecosystem where it may be more applicable, compared with the more complex JPEG 2000 and JPEG-XR. (In reply to mbrevda from comment #84) > It would seem that some of the "missing" things have been added: > * Alpha channel & XMP metadata > (http://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html) XMP is a better choice than EXIF (see https://en.wikipedia.org/wiki/Exif#Problems), so I can't see any objection based on features alone. Even though WebP is still a work-in-progress, this format does have the most support of any raster format since PNG, and may well have merit even if it turns out to be a flawed format. Either way, this should be looked into again with more data.

What other things is the newer version of WebP missing from what Mozilla requires? The new version with support for icc profiles, metadata etc looks pretty nice. Google said they have yet to optimise it's speed. Hopefully once the speed optimisation is done and a new build is released Mozilla will do some in depth tests and see if it is good enough to build into firefox.

This should be reopened as webp supports a lot of new useful features.

(In reply to Edward Webb from comment #86) > While I'm ambivalent to whether WebP is implemented on the desktop, > smartphone users would benefit from a version of Firefox with this format, > as users aren't just looking for the best formats in terms of image quality > and capabilities, but also on pragmatic issues such as speed and cost. This also applies when one is using an internet connection with monthly data-caps, like i do while travelling. When i am near my 1G data-cap at the end of the month, i sometimes turn off image display to save data. > Even though WebP is still a work-in-progress, this format does have the most > support of any raster format since PNG, and may well have merit even if it > turns out to be a flawed format. Either way, this should be looked into > again with more data. I would be really happy to see this re-evaluated. Also, i think that the webp guys would be happy to know what they should fix/implement.

There's an independent review of WebP's lossless capbilities by 'niezmierniespokojny' here: https://extrememoderate.wordpress.com/2011/11/28/a-web-centric-image-compression-benchmark/ In summary, he downloaded 6,000 random PNG files, and with the WebP-Lossless (WebP-LL) encoder, compressed them by an average of 22%. Without losslessly optimising the PNGs first, the difference is 34%. My own brief testing with other PNGs mirrored these results, ranging from 5-10% for PNG8 images, to 15-45% for PNG32. WebP will be implementing the following features that are missing from JPEG, PNG and GIF: * Lossy pictures with alpha support * 32-bit animation Which would be a practical replacement for JNG, MNG, APNG and GIF. There's no 64-bit support, which is unfortunate as WebGL developers don't yet have 16 bits-per-color images for textures (required for HDR) in lossy form. That would make JPEG-XR support necessary; but there's been no recent progress (see bug 500500). Firefox, Opera and Chrome have a combined marketshare of 42% on desktop (and rising), and 36% on mobile/tablets, according to NetMarketShare. Due to resistance from Microsoft and Apple to implement new formats, any new format would first have to support the majority of browser users to be successful. JPEG-XR and WebP are formats which have the potential to reach more than 50% of users, and become widely adopted. I think that JPEG-XR can co-exist with WebP, as there are sufficient differences between the formats that, in the event that both are implemented, they would be used for different purposes and compliment one another. If Firefox were able to implement both, we would be able to cover the limitations of existing formats; allow web designers and users to benefit; and encourage further development on the open web. While WebP isn't ready to be adopted yet, if Google can implement lossless and animation support - and those features can be fully utilized in image editors - we should be prepared to consider adding support for the format, for the benefit of web developers and users alike.

Are we still miss sth in newest WebP ? Looks like it integrate many features and it's ready to integrate into Mozilla products...

there has been no progress from google in months, maybe they have given up on it. x264 provides better quality to make screenshots from, maybe mozilla will use daala video codec to make images with, i believe that would be the best solution, it would probably take 2yrs or so but it would be worth it i think.

> there has been no progress from google in months, Last update was in december

Good to heard that, the new 'superior' image format is coming, but 2 years it a very long time in PC time. I see that Google implanted all what Mozilla wanted like: -lossless -animation -alpha channel = transparency -ICC profiles -XMP metadata so why not integrate it? We can always remove it later it it will become dead project which no1 will use.

Because they only implemented this in experimental branch. Experimental means it's subject to change.

Considering that it's been nearly a year since Jeff's blog post about this, and the improvements to the format since then, wouldn't it be time to revisit this ticket? Are there other features still missing that would block it?

Let them release a stable 0.1.4 version with all these new features first.

It's getting closer: https://groups.google.com/a/webmproject.org/group/webp-discuss/browse_thread/thread/afe32ecdb6046feb# I was not really impressed by the lossy part but the lossless one gives nice results compared to aging PNG, I'll post some results here shortly. Lossy + Alpha is a long awaited feature (JNG failed, JPEG2000 has weak support) I know dozens of webmasters that try to reduce PNG-32 file size and will fall in love with WebP once it's there.

Google has released version 0.1.99 of libwebp yesterday: http://code.google.com/p/webp/downloads/list https://groups.google.com/a/webmproject.org/d/topic/webp-discuss/D_fUrlSO888/discussion

v0.1.99 adds support for viz.alpha support and lossless support.

more info here: https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/webp-discuss/D_fUrlSO888

cwebp -lossless -m 6 -q 93 about-logo.png -o about-logo.webp about-logo.png 55620 bytes about-logo.webp 37566 bytes (about 32% smaller) The about-logo.png file is the Firefox branding logo, the smallest PNG file I could get optimizing it still counted a hefty 49502 bytes, see bug #653001. Replacing all the .png files inside omni.jar by .webp files would reduce its size, in the other hand adding the code to support WebP would increase its executable size.

I've conducted a short research with the latest WebP release and color type 6 PNGs (i.e. PNG24 with an alpha channel). I've seen that these type of images are: a. 14% of the image traffic on Alexa's 200K top sites b. Can be reduced to 20% of their current size by moving to lossy WebP. You can see more details here: http://blog.yoav.ws/2012/07/Images-Can-we-have-less

v0.2.0-rc1 is out now: http://code.google.com/p/webp/downloads/list Changes since v0.1.99: * Add support for ARGB -> YUVA conversion for lossless decoder New functions: WebPINewYUVA, WebPIDecGetYUVA * Add stats for lossless and alpha encoding * Security related hardening: allocation and size checks * Add PAM output support to dwebp

Hello there, I would like to help on this issue, maybe writing a new patch or working on the one already provided here in 2010. What is the amount of effort to do that task? Another point, there is a toolkit for encode and decode BMP, why not have support for WebP? Thanks, Matheus Morais

Hi, I registered to this portal only because of this one bug report. Hope this little post won't be deleted as "spam"- I've been using Firefox since version 2 and I've switched to Thunderbird with version 3. This year I've tried a lot of web browsers, Opera, Chrome, Midori, Epiphany, Rekonq, Qupzilla etc. but I've always returned back to Firefox, it's just the best one. But the recent changes in the project are disturbing me (the lack of HTML5 support, the abandonment of Thunderbird project, the lack of H.264 codec <although, that will land in FF someday, right?>, slow GTK3 porting, and the focus on B2G <the most stupid thing in the history of Mozilla> and ultimately, the need to differ from Google at all cost). I'm IT enthusiast and photographer, so I'm very interested in this topic. For now we are forced to use .jpg if we want to communicate with our clients, or simply public the pictures on web. And the 1986 codec is starting to lack the power we need in 21. century. That's where the three mayor browsers (Firefox, Chrome, Opera <listed by popularity :P>) should make their move and help improve the user experience on Web. So PLEASE reconsider the WebP as one of the supported file formats. Ally with Google on this one and help us, poor users, improve live on web. Thank you

I have to agree with this. WebP was born to replace JPEG, it was better than JPEG since the beginning, it has been adopted by major browsers like Chrome and Opera, it was a good opportunity to replace JPEG. They refused to support WebP using specious excuses about it not supporting features that JPEG doesn't support either (alpha channel etc.). This reminds me of the story about the guy who cut his own penis to spite his wife. P.S. WebP v0.2.0 final is out.

Dear firefox developers. Can You just implement WebP support and let webmasters to conclude which image format to use. The only reason, why WebP not used on my site is that Firefox does not support this format. http://bit.ly/fyd50C not actual after WebP v0.2.0 final is out. It's time to review Your point of view to WebP support.

webp is poor with black and white images according to a review of webp recently, maybe mozilla is waiting for this to be improved before adding support. WebP does have a lot of necessary features that it was lacking before so maybe mozilla could give an official statement soon.

The impassioned pleas are not really helpful here. The more of them you add, the less likely someone of consequence will bother to find the time to sort through them and find anything useful. A couple of years ago WebP wasn't ready; now it probably deserves a new look, and will probably get it... eventually. More comments here asking for it won't speed this along. ;)

Let's give Mozilla people some time to investigate new 0.2.0 features. Meanwhile, we could help them by 1) investigating at what Chrome version new features landed, and by 2) creating some tests to see how well new features work there.

(In reply to Max Stepin from comment #111) > Meanwhile, we could help them by 1) investigating at what Chrome version new > features landed, and by 2) creating some tests to see how well new features > work there. Careful now, we don't want the comments in this thread to become too constructive ;) Another useful bit of data would be performance comparisons for encoding/decoding speed on x86, x64, and ARM.

(In reply to Ryan VanderMeulen from comment #112) > Another useful bit of data would be performance comparisons for > encoding/decoding speed on x86, x64, and ARM. I can do the benchmarks for x86 and x64 and if I can use emulators in this test I can even test it on ARM (or is there such thing for Android?). Could you please provide link?

Unbelivevable, August 2012 and still no support. I just register in bugzilla only to fill this bug.

(In reply to glococo from comment #114) > Unbelivevable, August 2012 and still no support. > > I just register in bugzilla only to fill this bug. Maybe someone blacklisted WebP definitive and forget to check updates. Version -> 0.2 came out few days ago. https://code.google.com/p/webp/downloads/list

Yes, WebP support has been indefinitely suspended that's why it this bugfix is assigned as "Status: RESOLVED WONTFIX". It is a political, legal, and emotional minefield. Mozilla is directly funded by Google, they receive a majority of their funding from this source around $100 million in 2010 alone and last year $300 million, from Google being the default search engine. Mozilla likes to bite the hand that feeds to feel they have a little bit of freedom. And, Google has tolerated this instead of threatening to yank financial support, because they a) are a pretty nice company in fact they've increased their funding, b) Firefox helps make a dent in IE, c) they like open source, and, d) it spreads Google influence to users beyond Chrome which accounts for a large sum of target eyes. Mozilla realizes this and takes advantage of their position. They know Google won't bark or bite for these reasons. And, this is why they can get away with not following Google's grand plans. It is all about maintaining relevance and a large user count. The mpeg4 video and jpeg support, which makes up the keyframes in mpeg4 video, is the only way to get on all mobile devices equally. They were initially trying to follow Google's lead/direction and not support mp4 for HTML5. Then they realized that their user base wouldn't be as large today if they stayed on that route, and having a large user base is the only reason Google still funds them. Especially since mpeg4 is the doorway into mobile platforms. As long as Mozilla can maintain a large user base they don't have to fear Google ever dropping their funding. If Mozilla stops chasing that tail, then they will get eaten. Supporting WebP doesn't gain them users, and no one is going to stop using Firefox because they don't support a format that hasn't made an impact on the web. As long as Firefox doesn't support it, WebP can't make that impact. If WebP ever does make that impact, then Google being in control of that standard and the main force behind that code now has another standard that they can flex in the industry. If Mozilla ever loses Google's funding in the future, then it makes them beholden to a technology directly benefiting and controlled by Google in their own codebase. They would like to minimize that influence on their code by Google, i.e. we'll take your money but we control the code. Also, Mozilla still has hurt feelings about Google creating their own browser and this is a jab at they who would dearly like to see WebP supported on the web. What's interesting is that Mozilla does not just sit around and just hire employees, pay their expenses, and so on with all that money. They've been smart and they're investing a lot of it in businesses. When and if Google ever does decided to cut them loose, it'll hurt but at least they'll have a business model to fall back on. Not to mention they'd just make someone like MS (Bing) really happy. So, Google's hands are tied even if they decided to make threats/demands that things like WebP get supported. The irony here is that they already have WebP code in Firefox by supporting WebM. The keyframes in the WebM videos are actually WebP images. This is probably the best explanation you're going to get as to why WebP will always be ignored by Mozilla.

JNP & WebP : WONTFIX. What is the proposal for lossy compression with alpha layer ? With PNG, we can not use a large and complex images with transparency in web design.

*sigh* Please rethink WebP. I'd also favor to have that supported ...

(In reply to Célian VEYSSIÈRE from comment #117) > JNP & WebP : WONTFIX. Did you mean JNG? bug 88020 A mask image could be an alternative, well… only for webkit based browsers. https://developer.mozilla.org/en-US/docs/CSS/-webkit-mask-image

Safari has JPEG2000 support, IE has JPEG-XR support, Chrome & Opera have WebP support, Firefox has nothing fancy (APNG?).

@blakesteel: Interesting. Would it be possible to create JavaScript-code to convert WebP into a one-frame WebM? Until then maybe a decoder like WebPJS might be a good idea: http://webpjs.appspot.com/ But I really hate to have to consider such "hacks" :-(

> 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! Well, webp .2 now support all features that you, Joe Drew and Mozilla requested. I am not trolling here, and my post is not political. My post is technical. I am an web developper and as an developper I need an image format that have all features that webp offer today (alpha, animation, lossness, color profiles, better compression, etc). There are no other format will all these features and there are no excuses to Mozilla to not implement it. Mozilla advocate for the evolution and openess of web. Good words, but we need more than words, we neeed action. tThen please dont make same mistakes of microsoft blobking the evolution of web when they don´t implement webgl for example.

As many of you and specially "blakesteel" explained before, I'm reconsidering what FOUNDATION means to MOZILLA as FEDERAL means for FEDERAL EXPRESS. Both seems to use nice names but in the bottom are private companies running for money/profits, and for me, this seems to be far from Foundation as Wikipedia is and do.- I loved Firefox, I even make my T-Shirt from tshirtContest from someyears ago, https://en.gravatar.com/glococo But this and other politics (like divide&conquer in the mobile market) seems to go in the opposite direction of what netizens really need. Goodbye Mozilla. It was nice.

> 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! Please Joe Drew, claryfy us if your lie when you say words above.

google already offer a patch to mozilla to add support of webp 2.0 format in https://code.google.com/p/webp/downloads/detail?name=firefox_patch_libwebp-0.2.0.txt.gz&can=2&q= pleeeeease ! consider review and accept this patch ! we, webdeveloppers need this ! please mozilla, support us !

path from google to add support for webp .2

Originally uploaded to: https://code.google.com/p/webp/downloads/detail?name=firefox_patch_libwebp-0.2.0.txt.gz Note: This should make patch "path from ggogle" obsolete, since it was uploaded as a gz compressed file, but marked as a (text) patch. However, I can't mark it myself, so someone with the appropriate permissions please do so.

> 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! Please Joe Drew, clarify us if your lie to web community when you say words above.

I am continuously re-evaluating whether Mozilla should support WebP, in consultation with Jeff Muizelaar and other learned people. Unfortunately, while we have re-evaluated our position, my *conclusion* that Mozilla should not support WebP remains unchanged. If the market changes so that implementing WebP is more than a nice-to-have, or WebP becomes more compelling, our conclusion could change. Until either of those things are the case, though, I don't think it will.

how can it become more than nice to have or compelling? It already has nearly all the features you could possibly want with great quality and significantly lower filesize than .jpg and .png.

>> I am continuously re-evaluating whether Mozilla should support WebP, >> in consultation with Jeff Muizelaar and other learned people. >> Unfortunately, while we have re-evaluated our position, >> my *conclusion* that Mozilla should not support WebP remains unchanged. Lie and lie and lie ! before you say that Mozilla is concerned for Color spaces, Alpha channel, EXIF (or something similar, ICC color profiles, animation and lossness. Now webp has all features that you say are pre conditions to mozilla to add support for webp. Then you change you speech and say another lie. Mozilla don't want to implement an graphic format from Google. No problem, As an web developer I will make my sites to fallback to jpeg and png an gif in Firefox and the consequence is that in Firefox these sites will be more slow and uggly than in other browsers. In Android 4, chrome and opera it will be faster (better compression) and more beautiful (animation with true color, alpha and looseness). Maybe some users switch to other browser and left Mozilla... May be Mozilla lost some users... may be... Bad... Bad....

Can we just ban some people here? I see abuse in comment 131.

(In reply to Benoit Jacob [:bjacob] from comment #132) > Can we just ban some people here? I see abuse in comment 131. Looks more like an observation to me. :) But: can we all please shut up? This discussion and whining is obviously getting us nowhere, meanwhile each comment gets sent to 100+ people's inboxes, and that's even more annoying than the comments themselves. If you want to keep talking about that, why not start a thread in the mozilla.dev.platform newsgroup? You can also use Google Groups for that: https://groups.google.com/group/mozilla.dev.platform . That group is the proper place for discussion. This bugreport is not.

I see no reason to ban Benoit from comment 131. His points are all valid. He has reason to be frustrated with Mozilla for putting their goals ahead of the best interests of the web.

I concur with comment 134. I hope I speak on behalf of everyone here when I say the following. Perhaps you should read comment 131's post before you remove it and understand what his concerns are. What is abusive are unfounded conclusions regarding the inclusion of webp. Notice that no one is willing to indicate anymore the reasons webp is going to be passed up, because the excuses have run out. A foot is being put down without any substance other than abstract stubbornness. Do you grasp how much space on web servers will be saved by switching to webp? It will be a 2/3 reduction! Now compound that over decades or centuries and it really hits home. Not to mention the significant amount of bandwidth that would be reduced all around the world, it is enormous when you consider it. If anything it should be considered an environmental duty to the world to release this change. The amount of raw energy it would save the world is earth shattering. If anything, it would be both an economic and environmental boon. The bad economy, the unusual drought and hurricane seasons... Everyone should be doing their best to increase efficiency and reduce waste wherever possible. If you are just holding this change back for personal or political reasons, take that into account and reassess, please. Thank you.

Since there's already so much spam, I'm going to chime in here: As far as I'm aware, WebP still does not have a formally approved MIME type and file extension either in its spec or the IANA registry. It'd be kind of nice to have those things first so that authors don't have to deal with things like the JavaScript, Microsoft Icon, and XSLT MIME type messes or forever use/support an informal "x-" MIME type (as is the case with Adobe Flash). The spec is also in "working draft" status, so it's clearly not even finished being written yet. I think these requests may get more traction once Google has finished writing the spec. (That may be awhile though since Google is notorious for keeping its new technologies in a development state for very long periods of time.) And even if Mozilla were to implement this tomorrow, you'd still have the problem of Internet Explorer non-support which will be seen at the earliest via IE11. And that's assuming Microsoft agrees to implement it; they have their own competing format, JPEG XR/HD Photo, and already declined to implement WebM in favor of one of their own formats (H.264). Given Microsoft's rate of browser development and how long it takes for old versions of IE to become irrelevant, WebP-using authors will need to support fallback for years even under the best of conditions; you can simply provide that same IE fallback to Firefox in the meantime if you really want to use WebP now. (It might be a bit tricky to use HTTP content negotiation to serve fallback content though because of the MIME type issue...)

There, now Google has some things to address if they want to get Mozilla to support the format. * Get an official extension and MIME type added to the spec/IANA registry. * Finish writing the specification and officially release. As far as Microsoft not implementing anything when has this ever held back Mozilla? This one seems a poor argument. If anything Mozilla supporting the format would eventually bring support to IE faster, especially if it became popular. And, IE is becoming more and more irrelevant these days, according to sitepoint.com on the desktop market IE only has 38% all versions combined. Firefox has 25% combined, Chrome has 28%, Safari 6%, Opera 2%, etc. As far as I'm concerned IE is losing, and that is proof that their decisions about universal formats are not going to be as important as the ones chosen by alternative browsers. Combined alternative browsers have something like 62% of the desktop market, and around 83% of the mobile. That means we are making choices for the world now, not Microsoft. I think it should be our duty to pick open source patent-free environmentally and economically friendly ones. Maybe it will not catch on, but at least we tried.

I didnt make injury to any person in this bug report, nor spam, i just make technical arguments in favor of webp and I made valid tech arguments. I also point an mismatch betwen previous speeak of some guys and their actual speak. Simply, would be more honest and beautiful to admit that we do not want to implement WebP to benefit google. But they banned me because the true is not accepted here. Other users here agree with me, like Luke (134): > I see no reason to ban.... and blakesteel@gmail.com (135): > I hope I speak on behalf of everyone here when I say the following. > Perhaps you should read comment 131's post before you remove it and > understand what his concerns are. > What is abusive are unfounded conclusions regarding the inclusion of webp. But if Mozilla don´t accept valid technical arguments and if here is not an open source comunity, they can ban me again proving that they are not an open source organization. Also Patrick Garies , I note that WEBP already has an extension and an mime type: Filename extension: .webp Internet media type: image/webp But mozilla can say that they not have an standard mime-type only to FUD and to not implement the webp format if mozilla wants. If we dont want implement a format, we can say milions an milions arguments to not implement. I dont want to offend or injury any person, but in my vision these arguments are an lie, this is my vision. Sorry if someone think that it is an injury. I also can have my freedom to implement in my sites an fallback and make these sites feel bether in other browsers. If this is an injury to mozilla and they baned me, sorry for Mozilla, but the argument that they will lost the user base is valid, is true and is an tech argument. This is not political and is not spam. Is technical. But the truth hurts and some people do not accept that we speak the truth, they only accept what they want to hear.

image/webp also just seems to be a "proposal". Vendors like Opera and Apache seem to have picked it up already: https://developer.mozilla.org/en-US/docs/HTTP/Content_negotiation http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types But it is not yet IANA-assigned: http://www.iana.org/assignments/media-types/image/index.html http://bugs.python.org/issue11362 Also Google wrote (okay, back in 2010) that "image/webp" is/was just a proposal and that they'll need to reach out to IANA. https://groups.google.com/a/webmproject.org/forum/?fromgroups=#!topic/webp-discuss/FAaCCW5E__w

Stefan Neueind, also note that Google Chrome use image/webp. Also Russian Yandex Browser already support image/webp. Some telco already licensed from opera turbo mode, that also use image/webp. Seems that it is an "THE FACT STANDARD" MIME TYPE. In the last, some guys from w3c also advocate for webp adoption, see http://anselm-hannemann.com/blog/2012/04/14/a-chance-for-webp/ Only Mozilla don't accept this.

In addition, Python has already added the MIME type as image/webp: http://bugs.python.org/issue11362

One question: Why firefox support webm video if video/webm mimetype is not registered in iana ? Or this requiremet is only for webp ? my guess is from comment #138: > If we dont want implement a format, > we can say milions an milions arguments > to not implement.

(In reply to cesar from comment #141) > In addition, Python has already added the MIME type as image/webp: > http://bugs.python.org/issue11362 +1 As well as also Apache httpd web server (image/webp webp): on trunk http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types on 1.3.x branch http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types on 2.0.x branch http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/conf/mime.types on 2.2.x branch http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/docs/conf/mime.types on 2.4.x branch http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/docs/conf/mime.types SVN log message for trunk from Fri Mar 25 19:08:39 2011 UTC (WebP and Web font mime type) http://svn.apache.org/viewvc?view=revision&revision=1085522 "Add the WebP and webfont media types (that have not been registered by the same WHATWG idiots who regularly complain about servers not being configured correctly for mime types)." And several minutes before: SVN Log message for trunk from Fri Mar 25 18:40:31 2011 UTC http://svn.apache.org/viewvc?view=revision&revision=1085507 (WebM mime type): "Add the WebM media types (that have not been registered by the same WHATWG idiots who regularly complain about servers not being configured correctly for mime types)."

Just for the record, the mime type issue has no impact on the decision.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #144) > Just for the record, the mime type issue has no impact on the decision. What is still impacting the decision? Thanks.

(In reply to blakesteel from comment #145) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #144) > > Just for the record, the mime type issue has no impact on the decision. > > What is still impacting the decision? Thanks. Largely the likelihood of Microsoft and Apple also adding support.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #146) > (In reply to blakesteel from comment #145) > > (In reply to Jeff Muizelaar [:jrmuizel] from comment #144) > > > Just for the record, the mime type issue has no impact on the decision. > > > > What is still impacting the decision? Thanks. > > Largely the likelihood of Microsoft and Apple also adding support. That probability drastically goes up if we support it first. At the very least, Apple would support it. Microsoft will always be stubborn about open source standards. I've always seen Mozilla as a leader, not a follower. Here's hoping you change your minds. Thanks for the update.

Apple? Look at http://opensource.apple.com. I can see webp decoders in WebCore code. http://opensource.apple.com/source/WebCore/WebCore-7536.26.14/platform/image-decoders/webp/ for example.

(In reply to blakesteel from comment #147) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #146) > > (In reply to blakesteel from comment #145) > > > (In reply to Jeff Muizelaar [:jrmuizel] from comment #144) > > > > Just for the record, the mime type issue has no impact on the decision. > > > > > > What is still impacting the decision? Thanks. > > > > Largely the likelihood of Microsoft and Apple also adding support. > > That probability drastically goes up if we support it first. At the very > least, Apple would support it. Microsoft will always be stubborn about open > source standards. I've always seen Mozilla as a leader, not a follower. > Here's hoping you change your minds. Thanks for the update. The WebM support situation has shown that this is not true. In that case there was even more incentive to support WebM because there was no widely supported royalty-free options. In the case of still images we already have that with JPEG. Further, Microsoft has their own royalty-free image format, blessed by the same standards body behind JPEG that has already seen some adoption. (Windows, Flash, Rage, etc.) (In reply to max from comment #148) > Apple? Look at http://opensource.apple.com. I can see webp decoders in > WebCore code. > http://opensource.apple.com/source/WebCore/WebCore-7536.26.14/platform/image- > decoders/webp/ for example. Safari doesn't use those image decoders. It uses the ones built into the OS. I've seen nothing that would suggest that they are going to add support for WebP. They also already have support for JPEG2000 which is more mature than WebP and, according to some, gives compression improvements comparable to WebP.

FYI: Google keeps changing WebP specs: https://groups.google.com/a/webmproject.org/forum/?fromgroups=#!topic/webp-discuss/rDIDJEqJ8-c There is no point for others to implement a work-in-progress format before it's stable. Who knows where they'll end up eventually?

(In reply to Max Stepin from comment #150) > There is no point for others to implement a work-in-progress format before > it's stable. Who knows where they'll end up eventually? The irony is that Mozilla demanded those changes before they could consider the format complete. Google then implements the feature,so you can say "Ha! This proves it's a work in progress!" Also, the link you provided was discussing a completed feature and simply provided links to examples and API documentation on how to use it. It is almost as if you would like to have your cake, and eat it to. (In reply to Jeff Muizelaar [:jrmuizel] from comment #149) > The WebM support situation has shown that this is not true. In that case > there was even more incentive to support WebM because there was no widely > supported royalty-free options. In the case of still images we already have > that with JPEG. Further, Microsoft has their own royalty-free image format, > blessed by the same standards body behind JPEG that has already seen some > adoption. (Windows, Flash, Rage, etc.) To summarize, you are implying that Mozilla only follows Microsoft's lead. I am disappointed, but not surprised to be honest. It is generally bad idea to bet against Microsoft. This also makes me strongly suspect now that Mozilla is hedging its bets to potentially switch to Bing in the near future if Google ever pulls funding. It wouldn't behoove Mozilla to upset Microsoft by embracing non-MS open standards in the case. Well, at least we have our answer now. I think that puts to rest any hopes of this feature making it in. Thanks for the clarification. I officially give up.

Nothing ironic about it. The format *was* incomplete without alpha channel. What proves it to be a work-in-progress is not alpha channel implementation, but the fact that Google is going to add even more features, like animation (never requested by Mozilla, btw), and who knows what else, in the *future*. And you shouldn't be calling it a "completed feature" since the link is clear: "Note that animation related specification & APIs are experimental as of now." So *they* are saying it's work-in-progress. It doesn't make sense to chase a moving target.

Max Stepin, mozilla, and other guys: It is not an work in progress. There are several parts of webp that are finished and already supported from opera, chrome, golgle, yantex, safari and others. Is Mozilla Aurora an moving target ? Then we need to block all mozilla users from my sites (auora and non aurora) ? Also Javascript 6 is unfinished, does mozilla need to drop experimental es6 features from firefox ? Also mozilla need to drop prefixed css3 that are an moving target ? It will be more beautiful and honest to admit that mozilla dont want implement an imageformat from google. Period. Or implement finished parts of webp like others and implement unfinished parts in aurora. Also webp is open, mozilla can invlove and contribute to webp open source project. In the last JPEG2000 does not have the features that webp have, and we web comunity need an image format like webp that have JPEG/PNG/GIF/APNG combined in only one format. Please mozilla, support us, the web comunity. Honor what you says in your Company bylaws: support the web !

sorry, change safari to webkit: chrome, golgle, yantex, webkit and others

One more technical note: Google is adding features that community requested, they also implemented all features that Mozilla requested. Is this bad ? I think no. They will add support for sprites and 3d stereoscopic. There aren't an image format with all these features. we web developers need an image format like webp because these features. It is not for compression only.

(In reply to cesar from comment #154) > sorry, change safari to webkit: chrome, golgle, yantex, webkit and others Google Chrome, Yandex.Browser and Safari all use WebKit.

Aleksej Yes all use webkit, but safari don't support webp, only with an plugin. Also Yandex support Opera turbo with webp, that is not an webkit feature. There are several telco that use webp support from opera turbo licensed technology. The important is the whole post not this paragraph. The post says in summary that webp is not an moving target and is already supported by several parties ad that JPEG2000 and others formats don't have features that we web developers need to make web better !

from http://gs.statcounter.com in my country, Brazil: period : 1 of December of 2012 to 18 of December of 2012: Google Chrome Usage: 59,05 % Firefox 17,05 % IE 9: 11,53 % IE 8: 6,89 % With Opera, in Brazil, more than 60% of web users now can view Webp. If Mozilla support webp this will be more than 77% of web users that have webp support in my country. Also all Android users (here more than 80 % of mobile users are android) can view webp. One additional note: My company are converting all of our pictures to webp format and fallback to other formats in browsers like firefox and IE. Also we are stopping support for IE8 in our sites. In july of 2013 we will stop support of ie9 in favor of IE10.

interesting old post about webp. see in comments that all web developers want webp. http://blog.teamtreehouse.com/webp-38-9-faster-than-jpeg

JPEG vs WEBP Very interesting study... http://www.gaia-gis.it/raster_benchmark/jpeg-vs-webp.html The GIS community are also using WEBP. Cans someone comment this study ?

Torbis results after they converted their site to webp: http://torbit.com/blog/2011/05/02/webp-statistics/

cesar, They stopped listening 50 comments back. Thanks for your efforts, but they're falling on deaf ears. Mozilla has put it's foot down on this. It isn't going in. If we want progress you just have to tell your friends not to use Firefox, that is about all that can be done. This is a matter of case closed for them.

New article from Wired: http://www.webmonkey.com/2012/12/forget-javascript-its-time-for-browsers-to-speed-up-images/

Are you all already using JavaScript WebP viewers for WebM-supporting browsers?

I didn't want to post because of the etiquette which forbids comments that don't contain new arguments, but now I really feel like I have to post. @blakesteel: I don't think so. Every comment here is sent to more than 100 email addresses in the CC list, including me. While annoying the developers is probably not the way to get something implemented, I am sure they are still listening. As a website/server administrator, I am very interested in WebP; the only reason why I don't use it on my website yet is that Firefox does not support it. It makes no sense to store two copies of the same file on a server, like Josh Fraser from Torbit already said (link above). In my opinion, the arguments which caused the "RESOLVED WONTFIX" status are no longer valid; I request a reopening. It's a shame that the developers of a browser like Mozilla Firefox refuse to implement something like WebP; in my opinion, it is paradox. By the way, I wonder what would happen if Google decided to change all images on *.google.* to WebP. I bet Mozilla would implement it (who wants to use a browser which is unable to view images on a very popular website?). Someone needs to do the first step. That said, have fun discussing, I won't post a second time here until the request is reopened. "WONTFIX" is ridiculous.

(In reply to Tobias "ToBeFree" Frei from comment #165) > the only reason why I don't use it on my website yet is that Firefox does > not support it. It makes no sense to store two copies of the same file > on a server I think you would still need to keep two versions: WebP and JPEG, regardless of Mozilla's decision, for a very long time. > By the way, I wonder what would happen if Google decided to change all > images on *.google.* to WebP. I bet Mozilla would implement it (who wants to > use a browser which is unable to view images on a very popular website?). > Someone needs to do the first step. Google needs to do the first step by starting to use WebP massively on their servers, to prove they are serious about it, to prove they are not going to close it, like they did with so many "hobby" projects lately.

In reply to Max Stepin, > Google needs to do the first step by starting to use WebP massively on their > servers, to prove they are serious about it, to prove they are not going to > close it, like they did with so many "hobby" projects lately. They already made this, All their services, like picasa and gmail support webp. In Replay to tobias. We cant not support some browser that dont support webp. This is why google not convert all images to webp. In case a browser that not support webp, they fallback to other image format like jpeg/png/gif. In Reply to Aleksj: JavaScript has a lot of drawbacks. Also content negotiation is difficult to implement. The best method is detect browser that has webp support and serve css specific for webp. In our sites we make this. And finally a message to mozilla and "annoyed" mozilla's developers: Fallback in firefox, only makes firefox to perform slower than google chrome. The only looser is mozilla. It is all that google wants to erode Mozilla user base, when the mozilla not implement an feature like this and google do, normal users tends to fell that firefox is not a good browser.

My comment isn't about implementing WebP and I apologize for that, but I address our (web developers) concerns about WebP fragmented support (and try to move the webdev discussion to https://github.com/DavidBruant/ImageServerNego ) (In reply to Max Stepin from comment #166) > (In reply to Tobias "ToBeFree" Frei from comment #165) > > the only reason why I don't use it on my website yet is that Firefox does > > not support it. It makes no sense to store two copies of the same file > > on a server > > I think you would still need to keep two versions: WebP and JPEG, regardless > of Mozilla's decision, for a very long time. Agreed. Even if Firefox implemented WebP, you'd still need to serve images for IE10 which is going to stay for a long time (as usual!). Unless you're running Flickr or Facebook, I don't think you worry about duplicating images and your hard drive. Regarding maintenance of duplicated images, it sounds like something that can be easily automated. It's Mozilla's right to consider WebP not-mature-enough. That shouldn't prevent webdevs from using WebP where available. HTTP has a mechanism called server-driven negotiation allowing to serve different representations for the same resource based on the Accept HTTP header. That's the real way out to deal with different browsers accepting different sorts of image formats. There are complaints about the Accept header being not-that-helpful. I recommend all web devs to worry about this in priority: https://bugs.webkit.org/show_bug.cgi?id=105741 https://bugzilla.mozilla.org/show_bug.cgi?id=824623 (In reply to patrck from comment #167) > Also content negotiation is difficult to implement. How is it difficult to implement? In any case, that's what open source is about: find someone who's done the difficult part and just use it out of the box. If no such module exists, I feel we can write it. If web developers are successful in deploying WebP via server-driven negotiation, it may be a sufficient proof that WebP is web-ready and become an incentive for Firefox to support it natively. The good news is that once you have server-driven negotiation, you don't need to change anything the day Firefox supports it to gain the benefits of it. __Web devs__ If you want to continue the discussion about server-driven negotiation or webdev-related issues on dealing with fragmented image format supports, feel free to open issues or write wiki pages on https://github.com/DavidBruant/ImageServerNego Thanks :-)

As someone who actually knows how Bugzilla tends to work, I feel I need to explain something to those still reading new comments here, as many of the people in this bug have no idea how this system is actually used. A primary reason there's no new official Mozilla stance here is because there are over a hundred useless comments, ranging from just being in the wrong place to seriously bad behavior. Developers have a limited time to read the vast quantities of bugmail they get and they have to filter out the mess bugs like this one in order to function. I saw a blog post point people here to make their voice heard to push for this feature and it just has the opposite effect. This is not a forum, nor a democracy to vote in, and more noise is not helpful. A WONTFIX ruling like this is NOT permanent. This bug will be ignored until developers at Mozilla make the decision to revisit this, and let me be clear here, they will. They're a bit wary of WebP because it was first proposed with missing features and supporting new image formats is a bigger decision than it looks. You must also understand that WebP is associated with WebM, which Google screwed over everyone including themselves with for reasons that Mozilla still can't understand. That being said, if Google doesn't royally mess this one up too, I am quite certain that WebP support will be implemented and evangelized fully. It's just a matter of when and how. Just be patient until then and understand that you're not likely to get an ETA anytime soon. The only thing really useful to post here at this point are more links to new actual studies done on the topic (not just news blogs about it or the same data over and over again). Conversations about this without anything truly productive just clutter this up more.

Thanks Dave Garrett for clarification. I also suppose that links of wide adoption cases for webp from other parties (browsers, big sites and services, etc) are useful too to Mozilla.

Dave Garrett This is my last contribution for this bug request. Note that I am not making noise here and I do not post again here until the status wont fix was changed. This post is only to show for Mozilla developers the actual status of adoption of webp and reduce their fear. Software that support Webp: Google Chrome Win - Browser Google Chrome OSX - Browser Google Chrome Android - Browser Google Chrome Linux - Browser Android Browser - Browser Opera for Windows - Browser Opera for OSX - Browser Opera for Linux - Browser Opera Mobile - Browser Opera Mini - Browser Yandex Browser - Browser UC Symbian - Browser UC Java - Browser UC Android - Browser UC BlackBerry - Browser Apple Safari OSX - Browser (using Plugin) Google Chromium - OS Windows - OS (Google Codec) Linux Gnome - OS Desktop/App Plataform Apple OSX - OS (Google Codec for Quicktime) IOS - OS (using libwebp) Android - OS (ndk) Java - Plataform (ImageIo) Net - Plataform (github/codeplex imagewebp wrapper) JavasScript - Plataform (webpjs) Flash - Plataform (webp-plugin) Python - Language (pywebp) PHP - Languag (php 5.4 gd extension) Google App Engine - Cloud / Web Plataform Google Picasa - Web site - Pothografic Google Image Search - Web Site - Search Engine Google Plus - Web Site - Social Network GMail - Web Site - Email Service Torbis - Web Site - Optimizer Service Word Press - Web Site - Blog Magento - E-Comerce Solution Joomla - CMS Solution Acorn - Image editor Adobe Photoshop - Image Iditor (plugin) Corel Photopaint - Image Editor (plugin) GIMP - Image Editor (plugin) IrfanView - Image Viewer ImageMagick - Image Editor Pixelmator - Image Editor XnView - Image Viewer gThumb - Image Viewer for GNOME Konvertor - Image Converter ReaConverter - Image Converter Google libwebp - C/C++ Library javavp8decoder - Java Library javavp8decoder - Java Library GDAL - GIS On going Implementations: Konkeror - Browser Linux Kde - Desktop/App Plataform (Bug 267365 - Cheked in) Blocked implementations: Mozilla Firefox - Path submited - Wont Fix

(In reply to patrck from comment #171) That's interesting information, though your list is very very padded. That list is really: Google Chrome (desktop + mobile) Opera (desktop + mobile) Yandex Browser (mobile) UC Browser (mobile) Some Google Websites A bunch of image editors/viewers A bunch of libraries in different languages A bunch plugins to add support to programs that don't have it Gnome Google Android Torbis Word Press Magento Joomla Which generally can be summed up as Google supporting their format and Opera trying to support everything in existence, with a few other bits popping up here and there. Various image editing/viewing applications supporting it is obviously going to happen, and plugins are just plugins. Word Press support looks like it needs a plugin too. If someone big other than Google started using WebP, that would be a "Big Deal", but for now it's pretty much just them and some early adopters. Firefox implementing this would accelerate things but you'll have to be patient for that to be reconsidered.

Dave Garrett I'm sorry, I swear this is my last post, but only to supplement my list and regards of your reply, show to you that are not just a few Google sites, just open goggle chrome or opera, enter http://images.google.com and enter the query site:com filetype:webp -site:wpclipart.com Them you see not just a few Google sites, but thousands of web sites are serving webp today and they are faster on chrome and slower on Firefox, maybe even viewed in firefox in case of absence of an fallback for these images. Also, at last I want to comment that there are an extension to upload images in webp format to Facebook albums although Facebook don't serve images in webp. Thanks for all your comments and sorry again. I will be patient and not post again.

Supplementing the above list, note that webp can also be viewed on RISC platforms by using Netsurf Browser that include experimental support for webp in its last version. Also Wikipedia/Wikimedia opened a bug and accepted it and I confirmed from insiders that they are inplementing webp image support (This will be the "Big Deal" ?).

(In reply to patrck from comment #174) > Also Wikipedia/Wikimedia opened a bug and accepted it and I confirmed from > insiders that they are inplementing webp image support (This will be the > "Big Deal" ?). Adding the ability for WebP files to be used on Wikimedia doesn't mean they'll be converting everything they already have to it. If Wikipedia started dual-hosting all of their images in both WebP and JPEG, that'd be a "Big Deal".

(In reply to Dave Garrett from comment #175) > Adding the ability for WebP files to be used on Wikimedia doesn't mean > they'll be converting everything they already have to it. If Wikipedia > started dual-hosting all of their images in both WebP and JPEG, that'd be a > "Big Deal". They could use Google mod_pagespeed since it does on the fly WebP conversion. https://developers.google.com/speed/docs/mod_pagespeed/filter-image-optimize ModPagespeedEnableFilters convert_jpeg_to_webp Enabling convert_jpeg_to_webp causes the image optimizer to create webp images whenever it would otherwise create jpegs. The webp images are only served to modern browsers that support the format. Optimized jpeg images will continue to be served to older browsers.

from https://bugzilla.wikimedia.org/show_bug.cgi?id=25611 In en.wikipedia.org, a test script exists that replaces jpeg thumbnails with a (toolserver generated) WebP image. Add: importScript('User:Magnus Manske/webp.js'); into your user specific .js file (such as User:[Name]/vector.js)

After a little more research I found a lot of implementations of webp that I'm not previously post here. Some of these implementations are very important, like apache pagespeed module that are the actual responsible of thousand of webp images served in thousand of web sites on the web today (use Google image search to display them). Note that Krhonos, the publisher of webgl, now is supporting Webp too as part of OpenMAX IL 1.2 spec (an BIG deal?) Below is the updated list that I post here to update Mozilla knowledge of webp state on the web. Software that support Webp: Google Chrome - Browser (Win/OSX/Android/Linux) Opera - Browser (Win/OSX/Android/Linux/Mobile/Mini) Yandex Browser - Browser (Win/OSX) Android Browser - Browser (Android >4) UC Browser - Browser (Symbian/Java/Android/BlackBerry) NetSurf - Browser (experimental - RISC OS - Amiga, Atari and other exotic...) Apple Safari - Browser (OSX - using Plugin) mod_pagespeed - Apache module imageresizing.net - IIS module Google Picasa - Web site - Pothografic Google Image Search - Web Site - Search Engine Google Plus - Web Site - Social Network GMail - Web Site - Email Service Torbis - Web Site - Optimizer Service Word Press - Web Site - Blog Magento - Web Site - E-Comerce Solution Drupal - Web Site - CMS Solution Joomla - Web Site - CMS Solution Facebook - Web Site - (upload only - plugin - Easy Photo Uploader) Google Chromium OS - OS Windows - OS (Google Codec) Linux Gnome - OS Desktop/App Plataform Apple OSX - OS (Google Codec for Quicktime) IOS - OS (using libwebp) Android - OS (ndk) Windows Photo Viewer - (windows codec) Microsoft Office 2010 - (windows codec) Java - Plataform (ImageIo) Net - Plataform (github/codeplex imagewebp wrapper) JavasScript - Plataform (webpjs) Flash - Plataform (webp-plugin) Python - Language (pywebp) PHP - Languag (php 5.4 gd extension) Google App Engine - Cloud / Web Plataform Acorn - Image editor Adobe Photoshop - Image Editor (plugin) Corel Photopaint - Image Editor (plugin) GIMP - Image Editor (plugin) Paint.Net - Image Editor (plugin) ImageMagick - Image Editor Pixelmator - Image Editor RealWorld Paint - Image Editor Graphviz - Graph visualization FileOptimizer - Tool PentaSuite - pdf creation software XnView - Image Viewer IrfanView - Image Viewer gThumb - Image Viewer (GNOME) Konvertor - Image Converter ReaConverter - Image Converter Cocos2d-X - Game library - C++ SDL Library - Library Google libwebp - C/C++ Library javavp8decoder - Java Library javavp8decoder - Java Library GDAL - GIS Webkit - Framework OpenMAX IL 1.2 - Multimedia Language/API - Khronos Sepc On going Implementations: Konkeror - Browser (linux KDE) Ephifany - Browser (linux GNOME) Linux Kde - Desktop/App Plataform Wikimedia - Site Wikipedia - Site Blocked implementations: Mozilla Firefox - Path submited - Wont Fix Unknown if will support: Apple Microsoft Happy new year Mozilla Comunity ! I hope that Mozilla and the web community advance in 2013! !

Computer Vision Recognition Library are also supporting webp: Software that support webp SimpleCV - Open Machine Vision Framework OpenCV - Open Source Computer Vision Library (patch) Jan 2013 - Summary of actual state of webp: Webp is supported on almost any platform, from desktop to mobile. Webp is supported from two or more browsers on each platform. Webp is supported from a wide range of image editors Webp is supported from a wide range of libraries. Webp is supported from a wide range of programming languages. Webp have all features that Mozilla requested (Alpha, Looseness, ICC, Color, etc) Webp are implementing all features that community requested (Animation, 3d, tiling, css sprite) Webp is used to optimize traffic and make net faster by telcos, opera and others. Webp is used to optimize sites with Apache in thousands of sites. Webp is recognized by an standard body, like Khronos, and is part of an spec. Webp is recognized by community and wanted by web developers. Webp is not accepted by Mozilla.

Wrt Dave Ragget's > The only thing really useful to post here at this point are more links to new > actual studies done on the topic (not just news blogs about it or the same data > over and over again)." Google published yesterday their findings on switching the Chrome Web Store to WebP: http://blog.chromium.org/2013/02/using-webp-to-improve-speed.html Excerpt: "By converting PNGs and JPEGs to WebP, the Chrome Web Store was able to reduce image sizes by about 30% on average (here’s one sample image in WebP at 8.3kB and JPEG at 32kB). Given the number of requests Chrome Web Store serves, this adds up to several terabytes of savings every day."

Some day ago from Mozilla feed I read this article that I suppose was writed by a Mozilla employer: http://www.thecssdiv.co.uk/2013/02/images-why-the-right-format-matters/ It says: "= other image formats = There are other image formats, here are my feelings on using them on the web. bitmaps or tiffs Please do not use them in your websites. webp Something to look out for. This is a new image format and one that is said to provide images a good percentage smaller than both jpeg and png. *** The problem right now is lack of good browser support *** but it’s worth having a look out for updates on developers.google.com/speed/webp/." Who's now the murderess?

Firefox is an open source project. WebP is an open source project. So, why you don't integrate WebP in Firefox?

I think we should integrate the linux kernel in Firefox too.

I'm restricting comments on this bug. Please take further discussion to the newsgroups.

We decided to re-open this based on new data that shows that WebP has valid use cases and advantages. We will evaluate a refreshed patch and take it from there.

Looks like I can't undo the comment restriction, so I will file this as a new bug.

For anyone that would like a good short explanation of things, read this: http://arstechnica.com/information-technology/2013/04/chicken-meets-egg-with-facebook-chrome-webp-support/ For anyone ending up here, the second evaluation of WebP is in bug 856375.