Actually, that was just the result of abs(JPEG - WebP), which isn’t really that good of a comparison since it doesn’t indicate whether the WebP image was darker or lighter than the original – just that it was different.
Here’s a better comparison: 50% gray + WebP - JPEG (and highly enhanced this time). In other words, if a colour channel value > 127, the WebP was brighter than the JPEG original for that channel of that pixel; conversely if < 127, the WebP image was darker than the JPEG. Or, more intuitively, the yellow fringe around the top indicates that WebP compression yellowed the image (ever so slightly... like I said, it’s highly enhanced).
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
Good grief, you didn’t look very hard... they explained that at the top of the page:
o Note! For optimal display purposes and due to the large size of the file, we're presenting scaled down versions of the images here. o Numbers beneath the images refer to the original picture, not the scaled down ones. o Beneath each JPEG image is the file size of the original source image. o Below each PNG-contained WebP image are the file size of the original WebP image and the compression achieved. o To see the unscaled files, you can download a ZIP archive here (webp-samples.zip)
I suggest downloading them and using Preview to switch between the JPEG/WebP (converted to lossless PNG) copies. I find no perceptible difference.
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), 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!
JPEG makes things un-sharp because JPEG compresses gradients very well and compresses stark contrast very poorly. If you force it to compress the edge, it just blurs it.
WebP... I have no idea how it works. I’d presume that it compresses gradients well (to be a competing real-world image compression algorithm, it pretty much needs to), but it’s also feasible that it could act a bit like a sharpening filter.
However, I don’t think this is the case. I downloaded the full-size samples, and even switching between the two images, I honestly can’t tell a difference. Try it... download the images, highlight 2 of them, preview, tap next a few times just to lose track of which image you’re looking at, and then look for differences as you switch between them.
P.S. One of the articles linked to in the summary actually did compare JPEG and WebP on high-quality originals, complete with difference filter between results and original, but unfortunately it’s quite slashdotted at the moment. Try it in a few days...
Do you have any indication of how the edges differ, and which (if either?) is doing edges particularly inaccurately?
Unfortunately, no. Without lossless originals to compare them to, there’s no way of telling... the WebP algorithm was trying to recompress the JPEG artifacts from the original, after all.
The most significant thing that I noticed was the fact that the difference is quite significant in terms of hue. In other words, the difference map was colourful. JPEG, on the other hand, tends to introduce subtle value differences while trying to preserve the hue...
Yes... I also read the blog, where they gave a link to download the full-sized versions they used, along with the full-sized JPEG-converted-to-WebP-converted-to-PNG images to compare...
It had – a smoothing filter was applied to make the image easier on JPEG’s algorithm – and it saved another 15k or so. But here’s the non-smoothed version as well, weighing in at 105,798 bytes for a modest 84.4% reduction in size from the original...
Right. Still, most people wouldn’t notice unless you gave them both images and asked them to tell the difference.
Anyway, that was a drastic size reduction, which I intentionally did to exaggerate my point... naturally a less enthusiastic compression would yield meager reduction in size while being truer to the original.
A return to the days of "best viewed using Browser Z" is not in anyone's best interest.
Actually, I’d argue that it’s in everyone’s best interest – in the long run – as long as it’s best in Browser Z because Browser Z is rendering it the way the web standards say it should be rendered...
That’s not done in Javascript... it’s done in either flash, java, or some extra downloaded browser extension (they seem to change it on a weekly basis).
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...
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.
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.
If it’s just a “Li-Ion battery thing” (and it’s so predictable), the firmware could (i.e. should) be designed to compensate for it when reporting the % of battery life remaining.
Slashdot Mirror
Actually, that was just the result of abs(JPEG - WebP), which isn’t really that good of a comparison since it doesn’t indicate whether the WebP image was darker or lighter than the original – just that it was different.
Here’s a better comparison: 50% gray + WebP - JPEG (and highly enhanced this time). In other words, if a colour channel value > 127, the WebP was brighter than the JPEG original for that channel of that pixel; conversely if < 127, the WebP image was darker than the JPEG. Or, more intuitively, the yellow fringe around the top indicates that WebP compression yellowed the image (ever so slightly... like I said, it’s highly enhanced).
http://ompldr.org/vNXAydw/webp_vs_jpeg_gray.png
That would have been a super idiotic thing to do.
Specially if they intend to compare them to each other.
Hey... don’t look at me. I think it was pretty stupid too.
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
Good grief, you didn’t look very hard... they explained that at the top of the page:
o Note! For optimal display purposes and due to the large size of the file, we're presenting scaled down versions of the images here.
o Numbers beneath the images refer to the original picture, not the scaled down ones.
o Beneath each JPEG image is the file size of the original source image.
o Below each PNG-contained WebP image are the file size of the original WebP image and the compression achieved.
o To see the unscaled files, you can download a ZIP archive here (webp-samples.zip)
I suggest downloading them and using Preview to switch between the JPEG/WebP (converted to lossless PNG) copies. I find no perceptible difference.
I though PNG could do lossy compression.
It can... it supports indexed images, like GIF. Unlike GIF, though, it doesn’t have to... it also supports full-color RGB images.
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.
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), 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!
JPEG makes things un-sharp because JPEG compresses gradients very well and compresses stark contrast very poorly. If you force it to compress the edge, it just blurs it.
WebP... I have no idea how it works. I’d presume that it compresses gradients well (to be a competing real-world image compression algorithm, it pretty much needs to), but it’s also feasible that it could act a bit like a sharpening filter.
However, I don’t think this is the case. I downloaded the full-size samples, and even switching between the two images, I honestly can’t tell a difference. Try it... download the images, highlight 2 of them, preview, tap next a few times just to lose track of which image you’re looking at, and then look for differences as you switch between them.
P.S. One of the articles linked to in the summary actually did compare JPEG and WebP on high-quality originals, complete with difference filter between results and original, but unfortunately it’s quite slashdotted at the moment. Try it in a few days...
http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/
Do you have any indication of how the edges differ, and which (if either?) is doing edges particularly inaccurately?
Unfortunately, no. Without lossless originals to compare them to, there’s no way of telling... the WebP algorithm was trying to recompress the JPEG artifacts from the original, after all.
The most significant thing that I noticed was the fact that the difference is quite significant in terms of hue. In other words, the difference map was colourful. JPEG, on the other hand, tends to introduce subtle value differences while trying to preserve the hue...
Yes... I also read the blog, where they gave a link to download the full-sized versions they used, along with the full-sized JPEG-converted-to-WebP-converted-to-PNG images to compare...
I might as well add...
It had – a smoothing filter was applied to make the image easier on JPEG’s algorithm – and it saved another 15k or so. But here’s the non-smoothed version as well, weighing in at 105,798 bytes for a modest 84.4% reduction in size from the original...
http://ompldr.org/vNXAxcw/2_recompressed_b.jpg
(I saved the recompressed images at 55% JPEG quality – any lower than that it started showing noticeable banding in the blue background.)
Right. Still, most people wouldn’t notice unless you gave them both images and asked them to tell the difference.
Anyway, that was a drastic size reduction, which I intentionally did to exaggerate my point... naturally a less enthusiastic compression would yield meager reduction in size while being truer to the original.
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.
A return to the days of "best viewed using Browser Z" is not in anyone's best interest.
Actually, I’d argue that it’s in everyone’s best interest – in the long run – as long as it’s best in Browser Z because Browser Z is rendering it the way the web standards say it should be rendered...
That’s not done in Javascript... it’s done in either flash, java, or some extra downloaded browser extension (they seem to change it on a weekly basis).
orly?
apparently those are all generated from higher resolution source images
...which I downloaded. Here’s the difference between Cato June in JPEG and WebP, in full resolution, saved as a lossless PNG:
http://ompldr.org/vNXAxYQ/webp_vs_jpeg.png
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...
Difference filter on JPEG vs. WebP
Feel free to download it and increase the gamma to actually try to see the difference.
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
Recompressed JPEG: 90,930 bytes (86.6% smaller)
http://ompldr.org/vNXAxOQ/2_recompressed.jpg
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.
You expected less detail. You perceived less detail. /thread
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.
I would guess it's a Lion battery thing.
Why... from its predictability?
If it’s just a “Li-Ion battery thing” (and it’s so predictable), the firmware could (i.e. should) be designed to compensate for it when reporting the % of battery life remaining.
Really? It still works for me.
http://slashdot.org/story/10/09/29/1622250/Las-Vegas-Hotel-Vdara-an-Accidental-Death-Ray
If that still doesn’t work, try reloading with ctrl-F5 or clearing your cache.