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.
Microsoft releases a new image format called WebP (Score:4, Funny)
Apparently over at TG Daily Emma Woollacott [tgdaily.com] 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.
Re:Microsoft releases a new image format called We (Score:5, Funny)
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."
Not as Sharp (Score:4, Interesting)
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.
Re: (Score:2, Interesting)
I don't notice much loss of detail in the ones on http://code.google.com/speed/webp/gallery.html , it's just that the webP ones are darker for some reason.
There is no reference image, so I have no idea which is more correct.
Re:Not as Sharp (Score:4, Informative)
Cheekily, most of the WebP sample images on the page linked in the summary are higher resolution than the jpeg images they're compared to.
Re: (Score:2, Interesting)
Again without reference images, we can't really say which is correct.
Good catch on the resolution differences.
But it might be just a mistake, as in the footballer one they are both the same resolution.
The same for 1 & 9 too.
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!
Re: (Score:2, Informative)
Re:Not as Sharp (Score:4, Interesting)
Some people call them blurry, others sharper... there’s a whole lot of placebo effect going on here.
Download the full-sized images (webp-samples.zip [googlecode.com]), collate the pairs into separate new folders, load one up in Preview, and try to find the difference. Tap next a few times first to lose track of which one you’re looking at, if you want more of a blind test, then look back up at the title bar of the Preview window to check yourself...
My own verdict: No visible difference. None whatsoever!
Re:Not as Sharp (Score:5, Funny)
Re: (Score:2)
Re: (Score:3, Interesting)
Actually if you look at the football player, you can actually see artifacts to the right of the player's head, as well as a smaller, less obvious artifact halo around his body in the JPEG image, which is entirely missing in the webp image. Aside from that, everything looks more or less the same to me. Again, aside from the football player image, I wouldn't prefer one over the other which means, for me, webp is the winner.
A bigger questions is, with the rise of small computing devices, how does decoding perf
Re: (Score:3, Interesting)
is that still a viable solution?
I'm guessing this isn't really about getting a better image format. That is just a stepping stone to their real goal.
It shouldn't be too hard to get it put into a chip (for cameras, portable devices & media players). Once that is done
those devices should (with little modification) be able to use WebM video files too.
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.
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.
Sounds like a business opportunity to me (Score:2)
Think positively. It sounds like a business opportunity to me.
Think all the special power cables, wooden volume knobs, and the other BS that gets sold to "audiophiles" who don't, in fact, hear the difference, under the claim that it'll increase the fidelity when they listen to something off their iPod. You just need to add an organic, hand-tuned volume knob, and *wham* all those missing harmonics spring into place.
I for one welcome this new development and would like to offer videophiles an amazing DVI-D ca
Re: (Score:2, Funny)
Audiophiles don't use iPods. Crappy EQ. ;)
Re: (Score:3, Funny)
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.
Re:Sounds like a business opportunity to me (Score:5, Funny)
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".
Re:Sounds like a business opportunity to me (Score:5, Funny)
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.
Re:Not as Sharp (Score:5, Insightful)
Re: (Score:2)
I disagree. Look at images #3 and #4. The WebP versions are clearly sharper and more detailed than their JPEG counterparts.
Um, dude... you realise they generated that WebP image from the JPEG... there can’t be any more detail than the original. If there is, it’s a compression artifact.
Re: (Score:3, Interesting)
Actually, apparently those are all generated from higher resolution source images (which were previously JPEGs, yes, but at a higher resolution, so that presumably their prior JPEG compression is roughly irrelevant to the current round of compression).
Re: (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: (Score:3, Informative)
I don't agree. Take a look at the NFL logo on the football player's jersey just below his neck. If you zoom in and compare then you'll see the WebP version is crisper.
Are there any specific portions of the images where you feel JPEG has better clarity, so others can compare them as well?
Re: (Score:2)
Difference filter on JPEG vs. WebP [ompldr.org]
Feel free to download it and increase the gamma to actually try to see the difference.
Re:Not as Sharp (Score:5, Interesting)
I disagree with this. A music track exists to sound good, so degradation of quality transitively degrades its' purpose. However, not every image on the web was designed to be an artistic masterpiece. For most use cases, smaller filesize for slight drop in quality is a reasonable tradeoff. You can still use PNG for the stuff that you want to render just a certain way; remember, most of us have monitors that inject their own "noise" into the color spectrum of the photos we're watching. Besides, this is all up to the guy (or gal) hosting the website. Since (presumably) it's their content, I think it's fair that they have the choice to choose the quality/compression level that both saves bandwidth costs and looks good.
Re:Not as Sharp (Score:4, Funny)
A music track exists to sound good, so degradation of quality transitively degrades its' purpose.
Have you heard pop music recently?
Re:Not as Sharp (Score:5, Informative)
The images from the x264 comparison are the most striking. In particular, compare the parasol. With the H.264 keyframe, you can see the spokes and the structure. With the JPEG version, there's some macroblocking, but the features are detectable. With the WebP one, it is just a red circle. The rest of the image is similar.
This is really a shame. Replacing JPEG is probably worthwhile - it's an ancient standard in computing terms. It comes from 1992, making it about the same age as the web. We have almost two decades of image encoding research to build on since then and, almost as importantly, computers are now much more powerful. The first web browser I used was on a 386, which was just about fast enough that the modem was the bottleneck when decoding JPEG images. Now, decoding even large JPEG images doesn't tax my CPU, so we have a lot more cycles to play with for efficient compression. Things like JPEG-2000 provide this, but because they're newer there is a potential for submarine patents to cause problems for them (as happened with GIF).
The problem with replacing JPEG is the install base. Every graphical web browser since Mosaic has been able to view JPEG images. None can see your new standard (without a plugin). No existing image editors or cameras can generate your new standard (without an external program). Remember how difficult it was for PNG adoption, and that was with the threat of patent lawsuits for encoders.
Re: (Score:3, Informative)
I've slowly become a fan of JPEG-2000. For those that don't know, JPEG-2000 lets you encode the largest image once, then download only the amount of file that you need for the image resolution that you're displaying. So those 5 or 6 different size versions of your vacation photos in a gallery and the thumbnail on a server can all come from the same file.
There are also far less artifacts at lower bitrates.
There are a few other technological tricks in JPEG-2000, but those are the major ones. Sadly, as you
Re: (Score:2, Interesting)
Re:Not as Sharp (Score:5, Interesting)
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.
More accurately, WebP doesn't invent any additional detail. Look at the second image. Lots of artifacts on the background around his head. The WebP version is sharper, has less artifacts, and is a whopping 75% smaller.
Clearly WebP is especially good at photos with large areas of the same colour, something that JPEG has always been incredibly bad at.
Re: (Score:2)
I don't know why someone would mark this as flamebait. I'm just offering my opinion about what I see.
Re: (Score:2)
Placebo effect (Score:2)
You expected less detail. You perceived less detail. /thread
Re: (Score:2)
I was thinking the same thing, but I think the issue here is that the WebP graphics were compressed twice - to PNG because browsers do not currently support WebP.
The sample images were all pulled off of Wikipedia, and could have been JPEG to begin with, so you are then converting JPEG -> WebP -> PNG. WebP is a lossy compression format, according to the summery, so it only goes to show that if they are starting from a JPEG and recompressing, the WebP (and final PNG) will be worse than the original JPEG
Re: (Score:2)
Since PNG compression is lossless, it doesn't matter at all for the purpose of quality. Whether you had their webkit in your browser and had the image decoded directly to screen, or have it compressed to PNG first, is basically irrelevant. It'll look exactly the same.
Slashdot Experiment Time! (Score:5, Interesting)
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.
Re: (Score:3, Funny)
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.
I'm sure you'll spend an hour after work then. Thanks!
Re: (Score:3, Funny)
Yes, it'll be interesting to see the results once people do some blind studies on this
Blind people probably can't tell the difference between JPEG and WebP, but I don't think that's much of a selling point...
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.
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.
Re: (Score:2)
If it isn't supported by IE, it won't be of use on the web. Not that there aren't other possible uses for it, but that's a pretty important one.
Re: (Score:2)
Does Google really host that many images? What for?
Re: (Score:2)
Halo (Score:2)
I don't see that very annoying JPEG halo affect in the WebP image. Compare the blue background around the football player's head.
Re:Halo (Score:5, Informative)
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.
Re: (Score:2)
Affect is also a noun, though it isn't used that way very much outside of psychology. For example: "He has a cheerful affect, which leads others to like him." It's pronounced with the accent on the first syllable.
Re: (Score:2)
Effect is also a verb, although less commonly used that way.
Restarting again (Score:2)
And really, who cares about a wee bit increase in compression rate? Computers are getting faster, networks are getting faster and grander in bandwidth, a
Re: (Score:2)
You mean... outside the USA?
Re: (Score:2)
Well... (Score:4, Interesting)
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.
Re: (Score:2)
Oh, I'm sorry. I'll stop now. (Damn this iPhone4 display for tricking me into doing it!)
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...
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: (Score:2)
Do read the last link in TFS. They compress to the same image size and still WebP performs better. I for one would prefer a better compression algorithm that includes more detail for the same image size (Even if it is a 2MB file, I would prefer WebP to JPEG). Buts thats just me.
Re: (Score:3)
Actually, gonna agree with this guy. Especially if you twiddle the compression/optimization levels with software that supports them, e.g. GIMP.
Original JPEG: 677,662 bytes
http://ompldr.org/vNXAxOA/2_original.jpg [ompldr.org]
Recompressed JPEG: 90,930 bytes (86.6% smaller)
http://ompldr.org/vNXAxOQ/2_recompressed.jpg [ompldr.org]
Is there even a difference? Of course there is. Is it significant enough that your average web user will be browsing Sports Illustrated dot com and say “wow these images look crappy”? Hell no.
Re: (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: (Score:3)
I did a little looking to see how accurate this was and here is what I found:
MSN.com:
67KB Documents
84KB Images
286KB Scripts
Slashdot.org
121KB Documents
168KB Stylesheets
63KB Images
418KB Scripts
Digg.com
65KB Documents
60KB Stylesheets
378KB Images
240KB Scripts
Gmail.com (my Inbox)
931KB Documents
65KB Images
108B Scripts
1.33MB XHR
ps3.ign.com
168KB Documents
120KB Stylesheets
1.28MB Images
436KB Scripts
flickr.com
34KB Documents
5KB Stylesheets
165KB Images
2KB Scripts
cnn.com
172KB Documents
236KB Stylesheets
398KB Images
945KB Sc
Re: (Score:2)
That's why noscript and adblock can make certain sites so much faster. You only depend on one site working properly to see the page you want.
Whereas without the blocking, in order to see the page you depend on multiple sites (and their ISPs) to work properly.
Sure the 1x1 tracking pixel is
Re: (Score:2)
Actually, the OP *does* have a clue.
The reported justification for WebP is to reduce "latency" not "bandwidth use".
JPEG 2000 was boon (Score:2)
Re:JPEG 2000 was boon (Score:4, Insightful)
Why? (Score:2)
As long as crappy digital cameras save as Jpeg, people will use Jpeg. I'm not holding my breath. I also doubt anyone would bother converting their JPEG images to this new one, considering they're both lossy.
So honestly, what itch is being scratched here? Just a smaller filesize? Fear of bogus patent suits from dipshit and trolls like Forgent and Global Patent Holdings(both invalidated, but I'm sure patent trolls won't have any trouble finding anything even in a new clean-room implementation to sue over).
Gr
Re: (Score:2)
Except for all the photo sites. Just like YouTube the can transcode the images "most already do to make thumbnails". For them saving the bandwidth and storage costs may make it very worthwhile.
The problem will be waiting for Microsoft to support it.
Re: (Score:2)
That was my point. I don't expect them to change it. Somehow that sentence got clipped.
It should have read "As long as crappy digital cameras save as Jpeg, people will use Jpeg. Maybe they'll move to WebP, but I'm not holding my breath."
Blame FFB syndrome.
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: (Score:2)
I see no reason why would this be different than WebM (or the rest of the Webkit).
The format will probably struggle already to succeed, if they add cumbersome licenses so that Firefox doesn't add support for it they can shelve it right now.
Re: (Score:3, Informative)
Something suspiciously absent is any mentioning of license. I don't think it is necessary for me to describe why that's a problem.
See file LICENCE inside source package [googlecode.com]. It is 3-clause BSD licence.
Re: (Score:2)
I'm guessing that since it is the same algorithm used in WebM, wouldn't it have the same licensing (BSD) ?
Well, I don't believe the BSD license requires derivations to be similarly licensed so it could be anything. Worse... it could be nothing.
Is it free or is there intellectual encumberment? (Score:2, Interesting)
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 :-(
Re: (Score:3, Insightful)
Yeah, considering that this is /. I'm surprised not more people are asking about that right away.
Re: (Score:3, Funny)
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.
It's certainly a step up from JPEG, but... (Score:2, Informative)
Re: (Score:2)
Re:It's certainly a step up from JPEG, but... (Score:4, Interesting)
Problem is that, according to the analysis by the x264 developer (see the first independent analysis link), WebP is missing quite a few features that JPEG has, does not add any of the features JPEG is missing but people really want (like a lossy format that contains alpha capability - although admittedly, lossy compression of the alpha channel itself could cause some REALLY weird artifacts.)
It also, at least in the current state of the encoder, does not appear to perform any better than JPEG.
Re: (Score:3, Informative)
Didn’t look very hard, did you...
We plan to add support for a transparency layer, also known as alpha channel in a future update.
Why do a comparison without good data? (Score:4, Interesting)
Anybody know how it stacks up against JPEG2000? (Score:2)
Rendering Speed (Score:3, Funny)
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.)
Re: (Score:2)
On my system, the WebP images take seconds to render, where the jpegs are near instant. )
Clever trick seeing as you can't view webp in a browser yet. I expect you are viewing .pngs produced from the webps.
Re:Rendering Speed (Score:5, Informative)
They didn’t put WebP images in a PNG container. They compressed them as WebP, decompressed them, and then saved the raw pixels as PNG. PNG itself is a lossless format, so any differences you see between the JPEG and the PNG were introduced by the WebP compression. The PNG image is also on an order of 10x larger than the JPEG, which is why it takes longer to download/render on your computer...
Not another image format (Score:3, Insightful)
If it is going to be used instead of JPEG (Score:3, Insightful)
A Boon for Image Processing SW makers (Score:2)
Why, oh why? (Score:2)
Jpeg is mostly fine, even for high-quality real-world images if you keep to a high quality setting (95 or more). No visible artefacts, but a factor ten compression compared to good lossless formats. If you, say, want to store a copy of your film scans or other large images, high-quality lossy encoders can save you an enormous amount of space.
But there's one single problem with using Jpeg for that today: it doesn't support more than 8 bit data per channel. That makes it kind of suck as a lossy format for hig
Another problem solved! (Score:2)
Again (png), and again (jpg), and again and again.... Please, won't somebody think of the pixels?!
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 ign
Lenna (Karma Whoring with Naked Pic!) (Score:2, Informative)
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/ [cmu.edu]
It ain't gonna fly, Wilbur. (Score:2)
The comparison images that Google provides are practically worthless. They use the JPEG version as the original source material, and the WebP version is generated from that. All this is demonstrating is that WebP can recompress a JPEG and preserve the JPEG's existing compression artifacts. BFD. I don't care that you can reproduce a crap picture. Can you reproduce a good picture and make it look better at a given file size than the JPEG? The real test would be to compare a JPEG and a WebP both compressed fr
No alpha support? (Score:2)
Seriously Google, why isn't there any alpha channel in your new format?
You had the opportunity of merging the JPEG-like lossy image format suited for photos with the PNG-like alpha channel and you didn't take it?
Shame on you.
x264 WebP JPG (Score:2)
The guy at the englishhard.com makes a strong argument for x264 with a proper comparison with non-compressed images upfront. Google has a bad history of not being able to admit they're not the best at everything, and in this case, for my money, they sure aren't.
Awesome, just what the web doesn't need! (Score:4, Interesting)
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.
Re: (Score:2)
Well, Microsoft specifically licensed JPEG-XR's reference implementation in a way that prohibited using it with GPL code, so it's not surprising nobody is using it.
Re:Lenna image not shown?????? (Score:5, Informative)
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.
Re: (Score:2)
Perhaps we should standerdize on goatse?
Then again, it's already very low quality. Would anybody be willing to make goatse2010, as a stunningly high resolution PNG, and release under a creative commons licence?
Re: (Score:2)
Actually, the summary doesn't say anything about supporting it currently, but rather talks about which browsers will support it (read:in the future.) This there is no data on.