21–30 of 30 posts
It's important to note that this is a rejection of WebP, as it currently stands, not a forever rejection.
Google announced more features for WebP at Google I/O (including lossless and animation amongst others). I've not seen any Mozillan response to that as yet.
Is it really just because it was made by Microsoft?
I've yet to see a compelling argument for why I should want a browser with WebP support. Unless images start out lossless, and then are encoded into WebP directly, all I'll ever get out of WebP is smaller images that have more encoder artifacts - and I don't want that. I've got plenty of bandwidth; I'd rather download images in their original JPEG or PNG formats, especially if that means I can then open them up in an…
We don't have plenty of bandwidth with mobile applications. It's quite common for even basic sites to slow to a crawl on 3G. Even with LTE just around the corner, richer multimedia at higher resolutions will partially offset those gains. Note that according to Nielsen's Law bandwidth growth rate, while sill exponential, is slower than Moore's Law (transistor count) and Kryder's Law (disk space), so we will be increas…
Because mobile devices have screens with 300ppi it's not a bad idea to use GIF or PNG files with less than 64 colors (adaptive). When you use dither (patern) the results are quite good given the filesize.
The one time that I've found a practical application for WebP was when a client needed to fit a roughly 1-megapixel photograph in less than 5 kbytes of storage space. JPEG starts falling off a cliff in terms of image quality once you push it to extreme compression factors (like down near quality-0), but WebP degrades very gracefully and relatively linearly. The test images we put together turned into nearly unrecogni…
I believe WebM does (or at least the format can do) this automatically in low bitrate situations, without the external user needing to understand what's happening on the encode or decode end. I don't know if WebP inherits this trick and that explains it's low bitrate performance or if it's just better in other ways.
Earlier quoted context omitted.
Google announced more features for WebP at Google I/O (including lossless and animation amongst others). I've not seen any Mozillan response to that as yet.
"Google said they'd give everyone ponies! Respond!!!" Please point me to the roadmap document for WebP that shows which features Google intends to implement and the schedules (even rough guesses) for getting those features implemented. Without that, I don't see what there is to respond to.
https://groups.google.com/a/webmproject.org/group/webp-discu...
I personally am relatively comfortable with Google's throw it at the wall and see what sticks approach. I understand that others aren't but hope that Mozilla engages constructively so that WebP improves in a measurable way even if you/they have no intention of adopting it.
The "we need it to sit in ISO committees for 10 years before we can even think about implementing it" approach reminds me too much of the bureaucratic process trolling that Microsoft are so good at. It's good trolling because it's also a natural response and vaguely professional sounding, while still probably being either non-productive or actively detrimental to the technical outcome.
Note that from my amateur readings (notably http://sites.google.com/site/dlimagecomp/ms-ssim-results) JPEG-XR seems to be suffering from the exact problems that WebP is alleged to have (i.e. being designed for PSNR to the point that it's actually worse than venerable JPEG in SSIM and subjective tests). JPEG-2000 seems to have the same issue to a lesser degree. If Mozilla can bring some automated metrics to bear on this (and any parallel JPEG improvements), and metrics seems to be one of your/their strengths, then I'd be very happy, since it seems the JPEG-XR and 2000 teams may have been misled by their own metrics. Having multiple eyes on the problem, particularly those looking to find fault from the outside, would be great regardless of whether the result is WebP being improved or scrapped.
WebP should implement alpha transparency. That was in their promise but they never did it. That'd make it a jpeg-killer for me. A lossy image format that supports alpha transparency would be so great.
WebP should implement alpha transparency. That was in their promise but they never did it. That'd make it a jpeg-killer for me. A lossy image format that supports alpha transparency would be so great.
Alpha support is in the repo, marked as experimental: http://review.webmproject.org/gitweb?p=libwebp.git .
IMO the WebP project should focus more on this. It's a big thing, also on the web, to have a compact image format that supports partial transparency.
It blows away "simply using less bandwidth for photos" as an advantage, as it makes entirely new things possible.
Why not JPEG XR? It supports transparency, lossy and lossless compression, 16 bit channels, color management and has better compression. Is it really just because it was made by Microsoft?
1: "the visual performance of HDPhoto showed notable deficits, both in subjective and objective tests."
from Visual Quality Improvement Techniques of HDPhoto/JPEG-XR by T Richter
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04712398
Earlier quoted context omitted.
My apology for not being clear. The five points are summary of what you said and I hope there is no confusion. Right after the five points, I object to your "surgical arguments" which is along the line of "Jpeg is not too bad, and even if it is bad, there are ways to fix them". The truth is that Jpeg is actually a very poor format. Image artifact is very poor at low quality, and compression is very poor at high quali…
My position isn't that there's "nothing wrong or unfixable about Jpeg" at all. There's lots wrong and fixable with JPEG. My problem with WebP is that it currently doesn't fix enough of the problems that JPEG has and that if we adopt it right now we might end up with another format that still has problems and will have to replace WebP with yet another format that fixes those problems later. JPEG took 6 years to standa…
WebP is different from WebM in that there are IP issues. I think WebP is more like SVG/Canvas in that vendors don't see any "hurt" in supporting them once there is enough momentum behind. Of course, your point about making sure that we don't want to support any half-baked image format. I think WebP is beyond half-baked, and an initial pledge of experimental support -- instead of an outright rejection which seems to be tone -- doesn't hurt.