Google Releases New Image Format Called WebP 378
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.
Great. So? (Score:5, Insightful)
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.
True... (Score:3, Insightful)
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.
Re:Not as Sharp (Score:5, Insightful)
What a load a crap (Score:5, Insightful)
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.
Re:Well... (Score:4, Insightful)
There's always need for more compression. It all adds up. One loser at home isn't going to care, whereas an ISP with 20 million users might. Users might care when we eventually switch over to being billed by the byte, and being stuck on slow connections like cellular networks.
Compression and quality aren't the real problem (Score:5, Insightful)
Something suspiciously absent is any mentioning of license. I don't think it is necessary for me to describe why that's a problem.
Re:Well... (Score:5, Insightful)
PNG is a great format, but we don't need lossless for most pictures on the net.
Rather, rather than replacing everything with PNG, the web needs a lossy image format with alpha support and ability to do lossless when needed. Oddly enough, (currently) WebP does neither...
Re:Is it free or is there intellectual encumbermen (Score:3, Insightful)
Yeah, considering that this is /. I'm surprised not more people are asking about that right away.
Did you look at the originals? (Score:4, Insightful)
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.
Not another image format (Score:3, Insightful)
If it is going to be used instead of JPEG (Score:3, Insightful)
Re:Not as Sharp (Score:5, Insightful)
.
I'm very impressed with WebP overall. The images are sharper and have better colour tones, and obviously lack those awful JPEG colour smudges. The resolutions are unimportant - the important thing is that WebP produces the images at the same size at similar or superior quality. They are also significantly smaller.
I'd just like this opportunity to say "fuck the shitty Slashdot comments system". Try and guess which of the myriad reasons is causing me to complain this time!
OP Doesn't Have A Clue (Score:1, Insightful)
No, the OP doesn't have a clue and is just ranting.
This isn't about site loading speeds. WebP is about wasted bandwidth. Serving WebP versions of images for sites is going to be huge win in their bandwidth costs for virtually identical results to the end user's browser.
Holy flawed methodology, batman... (Score:2, Insightful)
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.
Re:What a load a crap (Score:2, Insightful)
So that only leaves one option: cui bono? Could Google want to reduce bandwidth just for its own benefit?
Solution: (Score:4, Insightful)
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.
Re:Rendering Speed (Score:1, Insightful)
There are no actual WebP formatted pictures there. Those are all standard PNG images.
Re:Not as Sharp (Score:1, Insightful)
Re:Rendering Speed (Score:1, Insightful)
Your computer is not rendering WebP, it is rendering a WebP image exported losslessly to a PNG. So you are just rendering a PNG.
Re:JPEG 2000 was boon (Score:4, Insightful)
Re:Not as Sharp (Score:3, Insightful)
Somebody moderated this overrated. I’m not sure why.
Maybe they thought I uploaded a black picture to be cute. I didn’t, but you’d probably have to tilt your LCD to notice that there’s anything there. Here... I’ll kick the levels way up so you can see the difference.
http://ompldr.org/vNXAyZw/webp_vs_jpeg_enhanced.png [ompldr.org]
Re:Not as Sharp (Score:4, Insightful)
So I downloaded them and I'm flipping between the two images. I agree that the difference is somewhere between bugger all and diddly squat.
For the preview images on the page I still maintain that presenting the two images side by side as they do is misleading given that they are pretending that it's "JPEG vs. WebP" when in actual fact it's "JPEG vs. PNG", since they seem to have compressed the right hand side with WebP at full resolution then scaled it down and PNG'd it, thus most likely hiding any artifacts.