Slashdot Mirror
Google Upgrades WebP To Challenge PNG Image Format
New submitter more writes with news that Google has added to its WebP image format the ability to losslessly compress images, and to do so with a substantial reduction in file size compared to the PNG format. Quoting:
"Our main focus for lossless mode has been in compression density and simplicity in decoding. On average, we get a 45% reduction in size when starting with PNGs found on the web, and a 28% reduction in size compared to PNGs that are re-compressed with pngcrush and pngout. Smaller images on the page mean faster page loads."
Why not update the png format? See subject.
Another unsupported format from Google.
It's interesting how successful they are at dominating/directing so many areas of the Internet, but they seem so ineffectual in other areas like this and the video format they are trying to get the world to switch to.
Yes, it's in TFA url and title. :)
... because Chrome is STILL NOT color managed.
The article title is: "Lossless and transparency encoding in WebP" So I'd say that's a yes on transparancy
...doesn't anyone think it might be time to revisit fractal image compression and maybe look at ways of improving iterated function systems and their associated algorithms (I might give Mike Barnsley a call and ask him how his IFS patents are developing if you're nice and mod me up)?
Operation Guillotine is in effect.
Gol-ly! Is there anything those Google engineers don't know?
Which Golden Girl would you plow first?
The cosmonaut of course.
Don't know something? Look it up. Still don't know? Then ask.
I didn't realize it was even possible to make such a big improvement in lossless image compression.
You falsely assume that PNG was state-of-the-art in lossless compression. PNG took a great idea (filter the image and take advantage of the 2-D correlation present in most real-world images) and coupled with it a terrible idea (zlib for the back-end compression of the filter output). You're supposed to do order-0 compression (ie. statistical, like Huffman coding) on the filter residuals, not pattern-match searching (zlib). zlib is a great piece of software, but like all tools, there are things it is very well-suited for and others it is not well-suited for. This was a misstep by the PNG team.
The choice the PNG people made was fueled by the Unisys GIF/LZW patent of the time, and at that time IBM also had a patent on range coders. So I guess it's understandable why they didn't use those order-0 methods on the filter residuals. But it was a huge mistake to knee-jerk away from ALL statistical methods and choose zlib as the back-end. They could have used basic Huffman; not sure why they didn't.
block google analytics.
Do you even lift?
These aren't the 'roids you're looking for.
Why, with today's bright screens, no one implements high dynamic range imaging in both GUI environments and common image formats?
"Paper white" is still "all bits on"...
As someone who would love to use variable transparency (translucency) pictures on my own website, this story is very cool news. For one thing, it allows pictures to have drop shadows on varied backgrounds, without having to be forced to save as full 32bit PNG.
I'm now somewhat disappointed PNG didn't get this far sooner. It's served its purpose well over time, but I didn't realize there was still so much room for compression.
Congrats to Google, and I hope the other browser quickly adopt this apparently great picture format. I wonder how its animation side compares to APNG or MNG. The PC has always been gasping for decent lossless animation support, even though the Amiga 20 years ago had seemingly a dozen animation formats to choose from. Also, web browsers have (or at least had) great difficulty in playing animations at higher than around 16-25fps (apart from flash). It's a pretty sad state of affairs all round really.
Why OpalCalc is the best Windows calc
Any smartphone user that pays by data volume would probably be better off with lossy image compression.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I just wish they'd change the name of the format. It feels awkward (in English) to pronounce WebP 'cause the "b" & "p" next to each other. I'm not exactly sure how that works smoothly, and I've noticed other people shy away from talkin' about it 'cause of it. That's a problem for any hopeful tech.
CSS3 will soon eliminate the need for rounded corner images and gradient backgrounds, and even smartphone bandwidth is increasing to reasonable speeds. Most ads these days are displayed with flash, and the quality of thumbnail images really isn't that important either
From the article thet seem to be targeting both lossy and lossless:
WebP was proposed as an alternative to JPEG, with 25–34% better compression compared to JPEG images at equivalent SSIM index.
and
Our main focus for lossless mode has been in compression density and simplicity in decoding. On average, we get a 45% reduction in size when starting with PNGs found on the web, and a 28% reduction in size compared to PNGs that are re-compressed with pngcrush and pngout. Smaller images on the page mean faster page loads
So their aim is to reduce bandwidth, which is admirable, yet the video side of Google is choosing to avoid H.264 which, AFAIU, has been shown to be better "bang for the bit" than VP8, and surely video is a far bigger consumer of bandwidth these days. (I'm not sure the unencumbered argument would stand up to close scrutiny).
As someone who rooted for the adoption of JPEG2000, I wonder, have we reached the point where the existing major image formats are 'good enough' and so established that new standards are unlikely to unseat them?
http://xkcd.com/927/
Let's be honest, vanilla PNG right now is only about as complex as running the deltas between neighboring pixels through deflate. PNG was clearly designed to do a reasonable job while not to taxing CPU or RAM.
That's a good thing. PNG is 15 years old now, from a time where a brand new computer had a 166 MHz CPU and 16 MB of RAM.
With how far computers have come since then, there is plenty of reason to want smarter compression methods and data filters in PNG, and the image format actually left a lot of room for adding new things.
Granted, any images that use these new compression or filtering methods won't be viewable with todays software, but if they end up in libpng, they'll end up being available to every program that uses libpng with absolutely no effort on the part of the developers of said programs, making it a way faster way to gain adoption than trying to get people to add support for an entirely new image format.
Any guesses on when IE will no longer define web standards?
https://upload.wikimedia.org/wikipedia/commons/c/ce/Internet-explorer-usage-data.svg
I'm guessing "now".
That seems like an oversimplification since the DEFLATE algorithm includes a huffman encoding step, and it is within the specs for the compressor to simply never emit back-references. It would be a horrible bug in the implementation of zlib to have worse compression performance than a basic huffman encoding.
Lossless compression and transparency are nice, but unless it allows for looping animated pictures of cats, I'm sticking with GIF.
Support Right To Repair Legislation.
PNG is well supported, free, stable and fast. 28% size gain on something that is not a major problem in the first place is kind of a weak argument. IMHO. The only thing that made PNGs so popular it that GIFs don't support 32 bit (RGBA) colors. Look at audio files : most people still use MP3 even if OGG is superior in nearly every aspect, simply because MP3 is good enough.
I'm sure that you didn't mean to leave all of the esteemed Democratic representatives that are co-sponsoring the bill: Rep. John Barrow [D, GA-12], Rep. Karen Bass [D, CA-33], Rep. Howard Berman [D, CA-28], Rep. John Conyers [D, MI-14], Rep. Ted Deutch [D, FL-19], Rep. Ben Luján [D, NM-3], Rep. William Owens [D, NY-23], Rep. Adam Schiff [D, CA-29], Rep. Debbie Wasserman Schultz [D, FL-20], Rep. Melvin Watt [D, NC-12]
Mobile networks are very constrained and, as many mobile device owners have noticed, the bandwidth is costly. A 28% delta in image traffic will inspire use. Have no doubt. Content providers are always eager to save bandwidth; images represent a large fraction of their traffic as well.
I found the WebP transparency mode to be even more interesting than the improvements over PNG efficiency. A lot of images are not lossy only because an alpha channel is necessary. WebP 'transparent' mode provides alpha with lossy compression. This could provide dramatic space saving for certain applications, games in particular.
The people of Papua New Guinea are not impressed
I'm working on it -- or rather squeezing every last drop of the existing format.
http://pngmini.com/vs-webp/
With good PNG8+alpha quantization you can get compression in the same league as WebP (although WebP is still better) and basically 100% browser support (it degrades well in IE6).
That seems like an oversimplification since the DEFLATE algorithm includes a huffman encoding step, and it is within the specs for the compressor to simply never emit back-references. It would be a horrible bug in the implementation of zlib to have worse compression performance than a basic huffman encoding.
(DEFLATE doesn't use Huffman, it uses Shannon-Fano as it's entropy encoding step.) While zlib can be configured to not emit back-references and just entropy-encode the input, PNG does not use this mode. I suspect it was because they were trying to stay as far away from the Unisys patent as possible (meaning, "image -> entropy" (GIF) and "image -> filter -> entropy" (PNG) might have seemed too similar/infringing).
zlib can not only compress worse than just entropy; if unchecked, it could actually output "compressed" data that is larger than the original. This happens when you give it uncompressable data and it tries to match patterns anyway. Of course it has a check for this; if the output is larger than the input, it just stores the input uncompressed. 7-ZIP LZMA doesn't have this, so that's why 7-ZIP's output can sometimes be larger than the input. (They fixed that in LZMA2.)
As I commented above, Googles engineers are either stupid or attempting to mislead people. WebP 'lossless' is not truely lossless as the charts on Googles page attest. For their comparison they take the raw PNG, resize using "convert infile.png -resize 240x outfile.png" then they convert to WebP 'lossless' then from WebP 'lossless' back to PNG.
The output of imagemagik convert already produces PNGs smaller than Google display in their comparisons. The discrepancy must be due to PNG struggling with the artifacts from WebP 'lossless' (ie: lossy) compression.
Here's the sizes from the resized tux image (sans transcode to WebP and back) and optimized with pngcrush, optipng and 7z deflate.
Googles examples show PNG at 40k and the WebP 'lossless' at 27.5k. There's no improvement from WebP, in fact it's worse because it's not truely lossless.
Using 37 topographic map png images ranging from 307K to 1.6M, the best compression I got was 4.09%
Typical compression was roughly 1.7%
In no way was I able to get 24% or anything close to that. But maybe I'm doing it wrong...
... by some bizarre attachment people had to creating multi-megabyte postage-stamp-sized 256-color videos with no sound using an image file format.
but zOMG kittehs!
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
The graph showing the additional compress ratio is a png.
Please don't forget to leave in support for metadata (e.g. EXIF). If PNG had this from the start, it's very unlikely that we would still be using JPEGs.
-Turkey
Which Golden Girl would you plow first?
The cosmonaut of course.
Heh... this could be the secret question/response to get into the "I browse at -1" treehouse. :3
Do what thou wilt shall be the whole of the Law
They are converting all of youtube to WebM, and it is the only royalty free web video codec. I'm pretty sure they will beat h.264 in the long run because free wins in the end.
The key word here is "converting."
H.264 is a core technology in digital video with 1,081 licensees. AVC/H.264 Licensees
Studio production.
Broadcast, cable and satellite distribution. Industrial applications. Home video.
You can play Google's YouTube transcode in your browser. WebM may find an anchorage in video chat.
But that is pretty much all you can do with WebM right now.
There is no such thing as amatuer or studio grade production hardware. No such thing as a WebM security camera.
Around 7.5 percent of browser activity is IE6, and that is most likely weighted by windows updates etc. About half of those users are in China, using pirated versions of Windows. You want to help hold back the web for the lowest common denominator? The implications are significant: 1) a worsened non standardized web experience for everyone. 2) perpetuating exploitable vulnerabilities that help the malware/trojan fest that the web has become. 3) keeping Microsoft and Windows XP relevant. Seriously is it that difficult to look at a user agent and have the site prompt for an install of Firefox or Chrome or Opera or Webkit to help further the cause instead of holding the progress of the internet back?
The kind of problems that surface are: proprietary control that keeps changing (eg like MS Office file formats), forking and fragmentation (eg like when each browser decides to support their own version of HTML), unforeseen security and extensibility problems, etc.
Just do it is the right way if you don't anticipate that many people will use it, but if you have a reasonable expectation that this will form part of the backbone of the internet, you should have a proper engineering review even though it takes years.
Then linked from the original article is the study is basing it on. http://code.google.com/speed/webp/docs/webp_lossless_alpha_study.html
It's essentially saying that nearly the entire reason it's a fraction smaller in lossless mode is because there's no alpha support. Combining it the "optional" alpha mode with the "optional" lossless mode merely makes it near-identical in size to PNG, according to them.
The more features you take out, and the more you degrade the pictures, the smaller they are in comparison to the original. Is this somehow surprising?
"A Goddess rarely smiles for she is forced by others to be an island unto herself." - Zephiris
why not just extend it and screw the committee?
Sounds like the the 2nd E in embrace-extend-extinguish methodology. MS did that with HTML, Java, and other technologies. I don't know about the other technologies, but HTML is a mess.
I've no doubt that WebP is an impressive now format, but the 28% quote can only be in comparison to an unoptimized PNG. Even using an archiver such as 7zip and feeding localhostr.com/download/JclO0Uh/ScreenShot2.bmp this image through every single one of its algorithms, the best improvement I could see was using PPMd on ultra setting with a 192MB dictionary and word size of 32. Total filesize became 3.23MB. The PNG that pngout gave me after one run was 3.31MB. So a 2.5% improvement using an archiver which does not allow for the decoding and vewing that normal image formats do. Running paq8px -8, which I would put forth as being one of the most extreme forms of compression there is, will eat roughly 1.5GB of ram and take 75 seconds to complete on my i7 920 @ 3.5ghz and the final filesize of that becomes 2.30MB, a 31% reduction. Decompressing that, by the way, will also eat a disturbing amount of system resources.
28% reduction over a png that was crapped out by photoshop's default and notoriously bad encoder, sure. 28% over pngout AND pngcrush? Hahahaha, no. Whoever achieved that would land themselves a Fields medal (basically the nobel prize of mathematics).
The one that still has a pulse.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Should be easy to beat PNG's compression. Offhand, I can think of several ideas that should improve on PNG:
1. Use bzip2 or xzip compression. PNG's compression is pretty much the same as gzip.
2. More compressible representation of the data. RGB values of individual pixels is really not very good for compression. There's stuff like YUV of course, but what I mean is some kind of transform to a frequency domain somewhat like what JPEG does. Then compress the data. This has been tried often before, without much effect. Too much work for too little gain.
3. Better filters. PNG's filters are fairly good and very simple. A little more sophistication and variety could pay off.
4. Most images compress better when oriented sideways. Why isn't this very simple 90 degree rotation transform used more often?
Which ideas does webp use? Haven't found anything that really says. Hoped the source code might have some of these details, but so far, haven't seen anything.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
I think there may be some confusion over mathematically lossless verses practically lossless, as there is a DCT involved here. If you do the math, then you can prove that it is lossless. But computers don't do the math that well - they introduce rounding errors in intermediate steps. This loss of information is often overlooked, as it isn't readily apparent in a purely mathematical analysis.
To a mathematician, pi goes on forever.
Might be an issue on mobile devices, but then given the cost of mobile data, I think I'd rather take the CPU wait.
Whoops, I totally missed that ;) thanks
GIF is always lossless for black-and-white and for color pictures with 255 or fewer colors. For pictures with more colors than that, it's always lossy.
PNG is a still video picture format. Why would anyone want to add animation to it? Just use MNG. That's the "GIF89a" equivilant of PNG. MNG is the "ANIM" to PNG's "ILBM", so to speak.
Daniel Klugh
"Only" 5-10% can amount to a lot, though, especially for bigger websites. I'm sure Google itself would benefit a lot from this 5-10% as they have a ton of servers working overtime to serve pretty much every internet user out there.
I am not devoid of humor.
But would you use an image format that's obviously meant to be used on the web there?
I am not devoid of humor.
That makes it limited, not lossy.
And JPEG is "limited" to those images that can be represented exactly with DCT coefficients that are multiples of the quantization matrices. JPEG compression is just rounding each 8x8 pixel block to the closest representable one, just as conversion to GIF is rounding each color to a representable one.
Save a file that was converted to 256 colors ten times more and the quality won't have degraded between the second and last save of that GIF file.
Open and save a JPEG with better than 8-bit-per-channel precision and use the same quantization matrix and the quality likewise won't have degraded. It's not like MP3, which uses a psychoacoustic matrix and overlapping transform blocks (MDCT) that let rounding errors accumulate and propagate to adjacent blocks more easily. Granted, JPEG will add noise if you shift the whole image by less than a multiple of the macroblock size, but then GIF will add noise if you paste in something with a different color scheme from the existing pixels.