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.
I don't see that very annoying JPEG halo affect in the WebP image. Compare the blue background around the football player's head.
Better known as 318230.
Submitter didn't even read Google's page on using WebP.
Since this is a new image format, you won't be able to view your WebP images in browsers or image viewers until support for the format has been provided for those programs*.
* The WebP team is proposing a patch to WebKit to provide native support for WebP, so you will be able to view your images in an upcoming release of Google Chrome.
What, and get back to waiting until it is supported and/or rewriting image tools to accommodate the new type? I've just had the (dis)pleasure of programmatically converting JPEG2000 images to JPEG and bitmaps, and I sure as hell don't want to waste more time writing yet another converter for a type that will be useless 4 months after I finish coding it.
And really, who cares about a wee bit increase in compression rate? Computers are getting faster, networks are getting faster and grander in bandwidth, and deadlines are growing smaller.
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.
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 cable that removes such WebP imperfections. For the low price of 499.95$, plus VAT, shopping and handling.
A polar bear is a cartesian bear after a coordinate transform.
The first and foremost image comparison should be the Lenna image.
No Lenna, no approval.
Lenna forever. Long live Lenna. I am lossless without thee.
Lenna, you make my pixels huffman.
Lenna you transform my fft.
----
http://en.wikipedia.org/wiki/Lenna
Meh. I always use PNG anyway. With the advent of faster web connections, there is no need for more compression.
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.
But very few companies embraced it. Just give a look to its capabilities!
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
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).
Granted, with the myriad image formats we have going around, what's one more... but honestly, when was the last time anyone used a ".PIC" file?
There's also JPEG XR (http://en.wikipedia.org/wiki/JPEG_XR) which was released a year and a half ago.
Don't think this or JPEG XR will gain much traction.
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 :-(
yeah, that's about it.
Colour is good enough and so is the size and no one is really in a position where the size of your images is a real issue.
The only people that will care are guys like Google or Facebook that have to host a billion of these... oh and porn collectors I guess.
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.
It'll be secure and work great until they add Javascript support
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?"
We already have a "better than Jpeg" standard that hardly anyone supports, JPEG 2000. Anybody know how WebP compares to this?
Does Google really host that many images? What for?
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.)
ever use Google Image Search? or Blogger?
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.
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.
http://alternatives.rzero.com/
You expected less detail. You perceived less detail. /thread
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
That'll be $200 to upgrade to the new version with WebP support.
How does this compare to Microsoft's HD Photo format, which is designed to span a continuum from lossless raw-quality through lossy all using the same efficient digicam-friendly algorithm? Team leader Bill Crow did many interviews on the format in photography circles and it sounded very well designed;
http://www.microsoft.com/whdc/device/print/xps/WMPhoto.mspx
Actually the OP's right. In my experience for many pages, I'm not waiting for the content to load, I'm actually waiting for some ad/tracker site's 1x1 tracking pixel, or banner ad or javascript crap[1], or css or whatever.
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 an image, but the fact it's taking time to load is not because it's gif, png, jpg or webp.
[1] FWIW Slashdot takes a lot longer to load when I turn on javascript.
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.
Finally, a working giant porn search engine. ...just booble it.
For sites that serve any significant number of images it will be a huge win to have WebP versions of their images and have the browser served the smaller WebP version if it is supported. It doesn't matter if crap browsers like IE don't support the format. The savings on bandwidth will be very large.
If anything it will make sites more hostile to IE since its users will be costing the site more bandwidth costs for the same content.
Image search. Those thumbnails (and the slightly larger "zoom-ins") on the new image search (the one that floods your page) take up a massive amount of bandwidth. Also anything that Google owns that displays thumbnails of any kind -- YouTube, Video Search, Google News, etc.. There's also Picasa, but I don't think that it's really a big bandwidth hog, comparatively.
Entomologically speaking, the spider is not a bug, it's a feature.
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 high-quality images. Any subtle tone shifts - a clear sky, for instance, or a near-white background - and you have visible banding. We have a possible contender - Jpeg2000 - that's been mostly rejected in the market due to the heavy thicket of patents surrounding it.
So what does Google do? They propose another image format without higher bit-depth support. And just to make sure that it's really useless for high-quality image applications, they restrict the image size to no more than 16383 pixels on a side. Anybody who has even played with panoramas with Hugin knows that you can easily get images larger than that.
So really, what is the freaking point? It doesn't do anything Jpeg isn't already doing well enough.
Trust the Computer. The Computer is your friend.
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.
The Football player pic is noticeably worse IMO, but considering they claim it to be a 75% reduction in size, that seems reasonable.
LOL, CAPTCHA: artifact
Again (png), and again (jpg), and again and again.... Please, won't somebody think of the pixels?!
Please do not read this sig. Thank you.
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
Image Search is an aggregating search service, it doesn't host images.
Just some little kid who rushed out his little rant hoping to score some karma.
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 from the same source source image. Then which one looks better?
Second, even assuming their numbers are accurate, the size difference isn't enough to matter. On average the WebP images are about 2/3rds of the size of their JPEG counterparts. Again, BFD. People don't care enough to bother for that little savings. You can get that kind of savings by dropping the JPEG quality factor a few percent, and the resulting image is indistinguishable to the vast majority of people. But no one bothers doing so. Why would they bother to use a new, largely unsupported image format just to shave off a few bytes? It's the 21st century, baby. Storage and bandwidth are cheap.
Yes, I know, cheap != free, and there are still applications in which storage or bandwidth are the bottleneck. WebP may find a niche for itself. But it's not going to replace JPEG in the vast majority of places where JPEG is being used now. Technically, WebP may be marginally better than JPEG. But that margin isn't going to be enough to overcome the nearly 2 decades' head start that JPEG has.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
Read the damn WebP sites own description:
"Webmasters, web developers and browser developers can use the WebP format to create smaller, better looking images that can help make the web faster."
So, no the OP running his mouth off doesn't have a clue. Nor do you.
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.
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.
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.
orly?
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Sure, in terms of you or I those thumbnails take up a lot of space. In relation to anything else Google does, they're small potatoes. The bigger ones might be taking up a little more, but not much compared to, say, YouTube.
This announcement has the air of marketing - someone mentions one day that WebM can compress individual frames better than JPEG and the boss immediately wants it packaged up as a JPEG competitor (we're going to take over the net!). He's not really interested in hearing that pretty much any reasonably modern image or video compressor is going to outperform JPEG.
Yeah, especially since no one on /. RTFAs... Since linked articles do cover this question.
retrorocket.o not found, launch anyway?
Originally the title read x264 > WebP > JPG but my less-thans got gobbled up. Also, sed 's/the//'
It's free, but every image contains your entire web history for Google to search. Muahahaha.
Colors seem a little strange..
I noticed there was some color variance in the example, so I actually looked at the VP8 spec and it is in YUV color space.
Which makes sense, VP8 was made for video.
However it appears there is a RGB to YUV color space conversion in the examples shown.
My graphic designer is going to cut my nuts off if I convert her images to WebP using webpconv.
To do this correctly I guess you should also source your raw material in YUV for color accuracy.
Believe me, purple is just not purple as i have been told. :-P
She is cute though, so I dont argue with her.
Does Google really host that many images? What for?
http://picasaweb.google.com/ perhaps? Google certainly re-encodes all the images that are uploaded. Though I don't see why they'd change the format, because they would still need to have the JPEG as a backup for non-WebP supporting browsers.
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.
I disagree to this.
Download the 2 pictures of the football player and swap between them in the image preview. While the difference between the images is extremely subtle, you will notice the webp is actually sharper. You can cleary see this the edges defining the top of the head of the football player the traits of his eyes are clearer.
The same goes for the painting. The painting in webp format is clearly not as blurred as the one in jpeg (just look at the face of the bishop, it's way blurrier in the jpeg version).
You've got to be kidding me. Here in 2010, 15 years after the web took off, I'm constantly waiting on web pages to load. Granted, images aren't as much of a problem as javascript, flash, and third-party requests, but come on. We have a LONG way to go before web browsing can be considered anything close to "instant", and yes, poor image planning is part of the reason. Or have you never tried to browse a forum where somebody posts 50 full-size photos exactly as they came off the 8-megapixel digital camera? You're damn right the solution is proper resizing and compression.
Three words for you: Picasa Web Albums.
I forgot about Picasa. Still, it can't be a drop in the bucket compared to the other things Google does.
It is unclear to me how quality was measured for all the graphs in the study -- was quality measured against the original image? I doubt that -- the images were harvested from Flickr, so the original (pre-JPEG-compression) aren't likely to be available. Instead, the quality was measured against the decompressed images, which have been blurred by the JPEG process.
If one wants to take one's collection of JPEG-compressed images and compress them further, without losing quality, one should decode the Huffman-encoded stream and re-encode using an arithmetic coder. One will save about 10% of the filesize without losing any quality at all. The Q coder is specified in the JPEG standard, so this can be done in a standards-compliant way, though no web browser supports that (which is a problem Webp also has).
It also makes you wonder if their algorithm depends on the jpeg pass in some way to get their great results. Its better than jpeg as long as you use jpeg first?
Yeah, especially since no one on /. RTFAs... Since linked articles do cover this question.
Hey, I at least glance over TFA. I did look over the Google Code page and saw zero mention of licensing.
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
We mainly use it because nobody has to worry about patents (that and, as you said, it's "good enough", but if it weren't for patent worries we'd conceivably be using something better than "good enough" by now).
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.
Google compares JPG and WebP at the same level of noise (PSNR). What is missing is comparing the same-size JPG and WebP images. If we can recompress JPEGs to the same size as WebP without visible loss of quality, or without loss of quality worse than WebP recompression, we should just dial down the JPG quality, not switch to WebP.
There aren't any "less-than" symbols in "x264 > WebP > JPG".
JPEG is based on DCT, the quality pics the scaling of the resulting matrix, then it is ordered and huffman encoded.
JPEG-2000 is kinda the same except it uses a completely different transform the naturally supports multiresoltuion: wavelets.
png/gif is different in that it doesn't use a transform, but just a variation on a loseless encoding called Lempel-Ziv-Welch (LZW ) named for the paper authors that worked on it in the 70's
What is the core math behind VP8?
Image search previews.
Google is presumably pushing this as a patent-free image format, something H.264 can't be. x264 is massively better because it's had a ton of time to mature, whereas the VP8 encoder only just recently had its code released, and is optimized much more for video than images. I suspect it would never be able to reach the quality that H.264 can reach, but it should still be way better than JPEG in the end.
A more fun question to ask is how long they'll be able to feign ignorance calling VP8 patent-free--analysis of it has shown that it shares a lot of the same algorithms with H.264.
And if it weren't for their paywall, perhaps someone could correct them.
Ceci n'est pas un sig.
So, if Google adds WebP support to WebKit, does that means that Safari (on Mac OS X, iPhone/iPod touch/iPad and Windows) automatically gets support for it?
@clone53421 they have mid quality thumbnails, not the full size originals.
The comparisons are against JPEG compression, but there is not just a single form of JPEG compression. Many parameters can be specified and adjusted. JPEG allows either Arithmetic and Huffman encoding, which effects the compressed file size. JPEG allows color space, quantization tables, and sampling factors to be varied which effects the final image quality. Yet the Google comparison does not mention the actual parameters that were used to produce the JPEG images. For this reason, the comparison becomes less than ideal.
I'm sure that the WebP format contains adjustable parameters as well, but these are also not stated. These image comparisons are poorly done.
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.
So? Millions/billions of thumbnails still take up quite a bit of space and bandwidth... saving even 5-10% on every thumbnail would be huge.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
gah... and what probably doesn't help Microsoft either is its constant renaming of the darn thing. Windows Media Photo -> HD Photo -> http://en.wikipedia.org/wiki/JPEG_XR
The page says so itself: "For optimal display purposes and due to the large size of the file, we're presenting scaled down versions of the images here."
The images are all scaled down so the appearance of macro blocking and other distortions is not as apparent. They're comparing files that are almost a megabyte in size, nobody will use these on the web unless it's deviantart, photobucket, flickr, or whatever. There is also a clear loss of color information, just look at the football player's head. On the other hand it seems to do a better job of preserving small details in #6 even at that scale.
Anyhow it will probably be suitable for typical web usage which is what they are going for, just not for featured images or archival purposes.
Twinstiq, game news
According to the renowned journalist Emma Woollacott from TG Daily:
Microsoft says it's developing a patch for WebKit to provide native support for WebP in an upcoming release of Google Chrome.
Microsoft's released a series of images for comparison, here
It's nice to see Microsoft and Google working in cooperation for a change. I applaud this revealing journalism!
And JPEG isn't not patent-encumbered like JPEG2000 is (as far as I know). I'd be surprised if WebP didn't have any patent encumberence (don't forget submarine patents or patent trolls just waiting for its adoption).
http://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio "When comparing compression codecs it is used as an approximation to human perception of reconstruction quality, therefore in some cases one reconstruction may appear to be closer to the original than another, even though it has a lower PSNR (a higher PSNR would normally indicate that the reconstruction is of higher quality). One has to be extremely careful with the range of validity of this metric; it is only conclusively valid when it is used to compare results from the same codec (or codec type) and same content."
They have this little feature called "Google images", you know, which has at least a gazillion thumbnails. They could make it 30% faster by using better compression.
A more fun question to ask is how long they'll be able to feign ignorance calling VP8 patent-free--analysis of it has shown that it shares a lot of the same algorithms with H.264.
If VP8 ever gets widely used, I suspect we'll find out very fast...
Folks, most of the WebP images were compressed from JPEGs.
From the article:
We expect that developers will achieve in practice even better file size reduction with WebP when starting from an uncompressed image.
It would be nice if they generated difference images from the original RAW and perform some quality measure to demonstrate the difference in performance.
I am becoming gerund, destroyer of verbs.
There's already a better alternative to JPEG that's more advanced than WebP. Microsoft's HD Photo is now JPEG XR, and it's out there now. It's implemented in IE9, so there won't be any struggles to get Microsoft to adopt it. Yes there are patents on JPEG XR, but Microsoft is making the specification open and letting anybody implement it that wants to. There are no legal problems to implementing open source encoders and decoders for the format, so there's no reason except blind Microsoft hatred to not add JPEG XR support to every web browser and make it the new standard.
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."
While this is definitely true, Google might just have enough force to push WebP into common use. Look at mp4's: mp3 was the de facto standard for a while because "everything supports it and it's good enough". Apple comes along with this iTunes music store and starts pushing their mp4-wares and support for the format actually started to increase.
That'll teach me to post before coffee.
Have you ever seen an AAC encoded file on the web? Safari probably supports them, but I doubt any other browser does (they all support mp3). My last little music finding expedition found AAC from Apple, mp3 from everyone else, and mp3 or FLAC from The Pirate Bay.
Apple's championing of AAC didn't have any effect whatsoever on web standards and the only real use of it seems to be in iTunes, which is end to end Apple and completely transparent to the end user.
Improving on JPEG's image quality is not hard. Improving on its deployment and compatibility status is very hard. JPEG 2000 and JPEG XR are both fine codecs, for example.
I think it's more the combination of it being an improvement AND their claim that it has no patent encumbrances. Otherwise they'd never get Firefox on board.
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.
Google claims that the codecs they back (In this case, VP8) are patent-free.
But apparently Microsoft claimed the same thing about VC-1, and within a year, numerous patent holders stepped forward with claims that VC-1 infringed on a patent they held, and now there is a VC-1 patent pool.
So really, "Unencumbered by patents" really means "We don't think it's encumbered but no guarantees."
retrorocket.o not found, launch anyway?
So really, "Unencumbered by patents" really means "We don't think it's encumbered but no guarantees."
Good point... unfortunately...
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
10 Mbps is pretty much the norm in smart phones these days. Why bother with image byte size, phone screens aren't that big anyways. Even highest quality JPEG loads more than fast enough. And technology is advancing to tens of megabits, next gen tech will hopefully bring 100 Mbps+.
Cable and fiber internet is 100 Mbps or better. And it keeps improving. Soon pretty much everyone who cares will have 1 Gbps connection at home.
Only video takes significant bandwidth anyways and even that isn't so significant anymore.
I'd say we should be way more worried about battery life than bandwidth. Bandwidth is a solved problem already. Image size? Who cares, even uncompressed BMP is acceptable with these speeds!
I can clearly see that the WebP images are more red/magenta than the JPEG files. I'd like to see the source images to see which format is causing more color shifts, and at what primary color intensity. Primary colors are what cause most of the artifacts because of how these lossy image formats separate the luminance from the color during compression.
Overall, it looks like the image formats are visually comparable, with WebP being a bit blurrier in detail areas, but showing much improvement in flat areas. I would like to have seen visual comparisons at the same file size. Making things smaller is nice, but bandwidth and storage get cheaper every day. How much quality improvement can I get for the same storage space?
CPU power and ease of design is the main thing. JPEG is specially designed to allow encoding and decoding with very little memory bandwidth, at the expense of compression ratio.
The reason is because JPEG can be encoded in 16x16 pixel blocks. No block depends on any other block, which allows encoders to only worry about a tiny part of the image at once. This allows each part of the uncompressed image to be read from RAM exactly once, and temporary intermediate "state" data is a fixed size which isn't proportional to the image size, which makes hardware design easy. Also, since there is independence between blocks, hardware encoders can be made which process many parts of an image simultaneously - thats how a cheap camera can compress a multi-megapixel image to jpeg in a fraction of a second.
The disadvantage of this is if all the 16x16 blocks in an area are very similar (for example a repeating pattern), the encoder can't know this, so there is minimal compression advantage. (I say minimal because another stage of jpeg compresson, the coefficient huffman tree might possibly help in some rare cases)
WebP on the other hand I expect chucks this idea out of the window in favour of compression ratio, but at the same time is also chucking out of the window the possibility of fast cheap simple hardware encoders and decoders.
Note that single-core software encoders probably aren't affected as much by this, and today most image decoding is single threaded and software based, so the impact may not be as large as I made out.
Ok new compresion, ok better, faster, but the real need is not on a static format.
Jpg performs quite nicely on photos, png works like magic on graphics but I personally would like to see a new engine similar to animated gif only with better transparency like png and more than 256 colors because working with flash is tiresome for a simple 123 animation and gets blocked most of the time.
About the issue at hand WebP seems much better than jpg on fine details with high contrast which is a particular flaw on jpg compression resulting in artefacts and overral muddy look.
If you don't look at the full size images, you're effectively just comparing a low-quality JPEG against a PNG. Of course the PNG is going to look better.
Scaling down the images makes the compression artefacts that were present on the original size practically disappear, so the only real differences are from the image format the small versions have been compressed with. Google should have used PNG for BOTH scaled down versions, but I guess that wouldn't have made WebP look so amazing for them.
I can't see much difference in the full-size versions. I think the only thing that can really be taken from this comparison is that it is possible to take an existing JPEG and re-compress it as a WebP without introducing any noticeable artefacts and at the same time reducing the file size. It would be much more interesting if they had taken an uncompressed source image and encoded it as both a JPEG and a WebP image. Even better if they could demonstrate what artefacts WebP does introduce.
Safari, Chrome, and IE 9 (sorta) support AAC, as does Flash. (http://diveintohtml5.org/video.html)
That said, you bring up an excellent distinction that I'd missed; I was speaking more of formats in general as opposed to in web standards. With that in mind, I think you're probably right. Web standards do tend to have a way of just hanging around in the stone ages. I mean, look how long HTML4 has lasted. And look at the GIF format, still fairly popular after all these years.
Doesn't mean we can't be optimistic though and hope that in the coming years the web can start to adopt some new, better standards.