Slashdot Mirror
Google Releases New Image Format Called WebP
An anonymous reader writes "Google has released WebP, a lossy image format based on the image encoding used by VP8 (the video codec used in Google's WebM video format) to compress keyframes. According to the FAQ, WebP achieves an average 39% more compression than JPEG and JPEG 2000 while maintaining image quality. A gallery on the WebP homepage has a selection of images which compare the original JPEG image with the WebP encoded image shown as a PNG. There's no information available yet on which browsers will support the WebP image format, but I imagine it will be all the browsers which currently have native WebM support — Firefox, Chrome, and Opera."
Independent analysis of WebP is available from a few different sources.
Apparently over at TG Daily Emma Woollacott thinks WebP is a Microsoft innovation. They've also reassigned Richard Rabbat to Redmond, which will probably be quite a surprise to him.
Meanwhile, in 2016 when the IE team gets around to implementing this image format they'll find a way to put an exploitable buffer overflow into it.
Help stamp out iliturcy.
I can visibly see a difference in ALL the pictures. The WebP version is slightly murkier and less shows less detail than the JPEG version.
It's like people say you can't hear the difference in suitably high-bit rate MP3, but I can - in the cymbals - they're not as bright as CD or FLAC.
This is kind of like that. It's ALMOST pretty great, but it's not as great. I guess if we all lower our expectations, we can get used to it.
JPEG was cutting edge a couple of decades ago but it's not very hard to beat now. We still use it because everything supports it and it's good enough.
From the x264 link:
What a blur! Only somewhat better than VP8, and still worse than JPEG. And that’s using the same encoder and the same level of analysis — the only thing done differently is dropping the psy optimizations. Thus we come back to the conclusion I’ve made over and over on this blog — the encoder matters more than the video format, and good psy optimizations are more important than anything else for compression. libvpx, a much more powerful encoder than ffmpeg’s jpeg encoder, loses because it tries too hard to optimize for PSNR.
These results raise an obvious question — is Google nuts? I could understand the push for “WebP” if it was better than JPEG. And sure, technically as a file format it is, and an encoder could be made for it that’s better than JPEG. But note the word “could”. Why announce it now when libvpx is still such an awful encoder? You’d have to be nuts to try to replace JPEG with this blurry mess as-is. Now, I don’t expect libvpx to be able to compete with x264, the best encoder in the world — but surely it should be able to beat an image format released in 1992?
Earth to Google: make the encoder good first, then promote it as better than the alternatives. The reverse doesn’t work quite as well.
This space for rent.
Meh. I always use PNG anyway. With the advent of faster web connections, there is no need for more compression.
That's because the scaled down preview JPEGs are compressed twice which is completely idiotic of course. Check out the unscaled images for the real deal.
Most of the formats in general use are over a decade old, and the company says that they're consistently responsible for most of the latency users experience
BULL SHIT! Images are nothing anymore. Its poor javascript coding, flash ads and all the dependent site components that are responsible for most of the experienced latency now. Images don't mean squat unless you're still on a 28.8 modem.
Also, one way you can make jpeg images smaller is to set the quality value to 75 or 80, most people won't notice the difference and the size of your image will reduce dramatically. The problem today is that people leave their images at full quality right off their camera and upload a 2MB image file when it really only needs to be 138KB. WebP won't fix that user mistake.
Something suspiciously absent is any mentioning of license. I don't think it is necessary for me to describe why that's a problem.
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
Is WebP free?
Does Google have any patent claims or other intellectual property claims (pending or otherwise) over WebP/
If so, then it is not free :-(
The main problem with new file formats is adoption. JPEGs have been the main image type online ever since the world realized that GIF sucked. Boards that allow image posting allow JPEG, social networks etc. which allow profile pictures allow JPEG, image search engines catalogue primarily JPEGs, almost every site's design utilises JPEGs. Offline it's the same; every OS which allows background images uses JPEG. Every image viewer and editor works with JPEGs. JPEGs have been an integral part of the internet for so long that I heavily doubt that any new format, superior or otherwise, will supersede them for a long time.
This makes no sense to me. The /. summary claims the webp images are built from the jpeg images. The jpeg images have already suffered loss and thus sacrificed image quality, and if correct any further processing will only be worse, never better. The proper test would be to make a comparison between two forms of lossy compression based on a lossless source (such as a raw file), which I suspect may be what really happened in the comparison. Of course, some people will take poor quality jpeg images and try to compress them further, but you can't blame the bad results this will produce on the new format technology.
I'm an American. I love this country and the freedoms that we used to have.
Yeah, considering that this is /. I'm surprised not more people are asking about that right away.
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
Did you look at the full size images offered for download? Because the ones on the page are scaled down, and any artefacts will be inherently "antialised" out. But when you look at them at 1:1 zoom and flip between the two, it's not hard to notice small differences. E.g., the wood texture in picture 4 is notably different IMHO and the chairs in 9 look IMHO blurrier.
A polar bear is a cartesian bear after a coordinate transform.
On my system, the WebP images take seconds to render, where the jpegs are near instant. This delay is even more noticeable on the last image of the tug boat. I know the memory/cpu trade-off laws, but is this trade-off worth it now? Will this format have to wait until people have better CPUs? They said they put the WebP images in a PNG container, is that affecting rendering speed?
(I have some random Intel Duo, Chrome, Win7, on a FiOS line.)
Great that you have read the article you apparantly did look at:
The photos are licensed under a Creative Commons License. Famous classic images such as Lena, the Baboon, etc., often used when doing compression comparisons, are unfortunately not free of copyright.
I can only read this with horror -- yet another lossy image format to burden everyone. When I setup a media management system the number of different formats I need to accommodate already makes my head hurt. We are all dancing around the black hole that says the ultimate lossy compression can be achieved by writing to the null device. I guess that is the problem of software -- since it is intangible one can claim better by making it different (and incompatible). One sees few cars on the road with five wheels -- that standardized pretty quick and a long time ago. And I guess everyone likes keeping it art rather than science. Means 'engineer' is just a courtesy.
If it is going to be used instead of JPEG they are going to have to include EXIF data/. I am not clear whether you can currently, evidently some RIFF-based formats can but I am not sure whether just using RIFF enables this.
No no, you're missing the point. People here only care about something being free if it gives them the chance to bash microsoft or apple. This would only give them oportunity to bash google, so it's inaplicable.
You'd be surprised what some use.
E.g., I remember one case from another board who was hearing differences in sound quality when playing MP3's off different hard drives in his computer. And no, he didn't mean the HDD's own noise. He was convinced that it's like on the old cassettes, where different kinds of tape (e.g., iron vs chrome) had different frequency responses. So it stood to reason to him that some HDD's have better bass than others.
A polar bear is a cartesian bear after a coordinate transform.
They're comparing webP to jpeg by testing how well both algorithms can recompress (a set of almost entirely) jpeg images? Really? Really???
More to the point, jpeg compression artifacts (discontinuities) are a *nightmare* for wavelet coders, so this is in no way fair to jpeg2k.
Also, from TFA:
Predictive coding uses the values in neighboring blocks of pixels to predict the values in a block, and then encodes only the difference (residual) between the actual values and the prediction. The residuals typically contain many zero values, which can be compressed much more effectively.
WTF, this is exactly what a wavelet coder like jpeg2k does, only in a much more sophisticated way.
This whole thing is so far below any accepted standard of image compression research, it should just be silently ignored.
I thought Playboy relented (just said the hell with it), and released Lenna (the head shot version) to public domain for research purposes?
Anyways, what people use to consider porn linked (now it seems like tasteful art :) ).:
http://www.cs.cmu.edu/~chuck/lennapg/
Atlas Shrugged : Thematic Story
Good point, a real addition that would be beneficial to mitigate uselessly big photo's would be an image format that contains a thumbnail, small version, larger version and huge version of the photo in progressive order and only downloads the parts needed to display at the size on the screen. JPEG and GIF supported progressive images, with WebP they could enhance on this to have some real images within boundaries clearly segmented in chunks... So when a user uploads a 16MP photo and the website displays it at 320x240 you only download the first two chunks, unless of course you zoom in and the browser downloads the rest of the same file. When launching a new format they have a chance to create something a little revolutionary, the work to add the code to all browsers needs to happen anyway.
Multiple chunks in progressive sizes will get rid of all the extra thumbnail and small version files that need to be created, stored and downloaded. For example searching an image on Google image search shows:
- 125x125 thumbnail in results
- 250x250 zoomin thumbnail over results
- 550x550 preview over webpage (scaled version of full image)
- 16MP image when downloading
When for example you don't like the preview image and don't want to save it you will still have downloaded several MiB... very wasteful, and my cache is littered with several thumbnails per image.
With the progressive chunked version you would only have downloaded the first few percent of the image until 'chunk_pixels > viewport_pixels'.
Some other advantages:
- VP8 is a video codec, so you can predict parts of the larger chunks based on the small chunks before that (basically a gradually focusing video). It may require some specific optimizations but should not increase the total size by a lot (so thumbnails are a free bonus).
- The images are displayed faster while loading, and not top-down but gradually sharper (the old advantage of progressive encoding, but fuck those JPEGS were ugly).
- You can display a photo at a low resolution on the webpage but still get sharp high resolution prints without wasting bandwidth of all users just viewing the page.
- This will make it easier for browsers to scale down large images smoothly (try viewing a 50MP image, no browser scales that smoothly) without requiring massive amounts of CPU.
- Reduce bandwidth, storage and caching requirement for websites and for clients.
So Google if you want to save bandwidth: make a format that stores large images in progressive chunks so browsers only need to download as much of the image as is needed to display the current size on screen.
Storage space is cheap.
Computation is cheap.
Bandwidth is not.
"Are you offering to recode all of these sites to support both WebP and non-WebP browsers?"
Why would anyone give a damn if a site is dumb enough to pass large savings in bandwidth for serving the exact same content?
It's a known fact* that electricity from hydro has a smoother, more natural sound than electricity from nuke plants. Coal is somewhere in the middle of the two.
I've heard people claim "Most people can't tell the difference between .01 and .05 THD, but I can." Which is like saying "Most people can't read the surgeon general's warning on a pack of cigarettes from a half mile away, but I can."
---
*among wacky "audiophiles".
The assumption with JPEG2000 is that it's going to be torpedoed by some jerk with a patent if it ever takes off. That's why nobody is willing to invest too heavily in it. They were already burned by GIF, they learned their lesson the first time.
I read the internet for the articles.
If you already know which is WebP and which is JPG, you're unavoidably biased. We're not going to settle this without a blind trial.
Slashdot hackers! Your mission, should you decide to accept it, is to write a little website which encodes a series of raw never-been-compressed images as WebP and JPG of equal sizes, presents both side-by-side to the user, and has them click on the one they think is "better". Do not label which image is which: randomize them. Collect statistics and present the data on the site.
Any good php hacker should be able to whip this up in about an hour. I'd do it, but I've got work to do.
Nuclear power is great for Heavy Metal, but I always ask my power company to switch me to green electricity before listening to Irish music.
The JPEG standard is not perfect. There's several more efficient and effective image codecs available now that were impractical in 1992. However it's relative simplicity and age mean it is trivial to handle on contemporary machines and is available everywhere. Just about any graphical web browser you can find supports JPEG images. While WebP might offer best case space savings over JPEGs of equivalent size the idea that it's somehow appropriate for mass consumption is absurd. The justification of JPEGs slowing down load times for web pages is ludicrous, JavaScript doing a half-assed job of loading resources and unoptimized server access causes far more problems than additional kilobyte in an image. It's yet another half-baked Google project released because there's not enough parental supervision going on.
WebP does not offer any compelling reason except a promise of space/bandwidth savings over JPEG. It doesn't currently support multiple color spaces, color correction, an alpha channel, or animation. It's promise of space savings at various quality levels is ridiculous because like they did with VP8/WebM Google is only focusing on PSNR measurements. PSNR makes for nice graphs but is not an effective measurement of how images actually look to people. An image that scores well in a PSNR test might look like shit when you actually compare it to the source image. Most JPEG encoders are tuned for psychovisual performance, not to score well in PSNR tests. Testing WebP vs JPEG with VQM tests would be far more appropriate but I suspect WebM would do far worse than with PSNR (since that's what VP8 is tuned for).
Without a VQM test it's really not appropriate to say that at a given size WebP has better visual quality than JPEG. Even if this turned out to be the case it's missing a lot of other important features that JPEG either has or a truly viable replacement for JPEG should have. WebP only supports a single color space and color profile so if your source images look like shit in that space or with that profile you're out of luck. JPEG can declare an image's color profile or provide its own ICC. It doesn't support lossless encoding or an alpha channel (right now) so it won't be appropriate to replace PNGs and GIFs which are often less optimized for the web than JPEG. It also doesn't support animation which for good or ill is still an important use of GIF files.
Yet another image format to not get widely accepted on the web doesn't do anyone any good. Why not help support JPEG-2000 or JPEG-XR? Help PNG out with a F/OSS compatible LZMA library. No camera manufacturers will support it because they can't just write a few Exif tags and attach an ICC profile and have a usable image. Converting your personal library means you get not only a lossy-to-lossy conversion but lose the ability to do lossless editing (rotation etc). Because WebP has more complicated encoding than JPEG it's going to require more CPU power to decode, your iPhone an Droid will get worse battery life browsing WebP content than JPEG content. The reduced file size (assuming WebP lives up to its promises) isn't going to make up for the vastly more complicated decoding. So hooray, Google managed to reuse their VP8 encoder for still images while simultaneously not solving any actual problems with images on the web.
I'm a loner Dottie, a Rebel.
Apparently over at TG Daily Emma Woollacott thinks WebP is a Microsoft innovation.
She fixed that oversight. But now she seems to think that Google Chrome is a Microsoft product:
"...but Microsoft says it's developing a patch for WebKit to provide native support for WebP in an upcoming release of Google Chrome."
Microsoft is the blue e that you click to get to the Interweb. Google is the place you type in the website you want so you can go there.