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.
Last time it was planned as an upgrade, has the alpha channel made it to the improvements? It's a bit sad to release an image file format for the future of the web that doesn't support transparency IMHO
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.
... because Chrome is STILL NOT color managed.
I didn't realize it was even possible to make such a big improvement in lossless image compression. The web definitely needs it - any smartphone user that pays by data volume can confirm this.
Very important for certain classes of photos, medical images for example. Doctors cannot allow any loss to the image due to liability and the chance of the "lost" resolution of the image leading to a missed or incorrect diagnosis. Another is pictures of the Golden Girls. No way I want any loss of quality there.
Which Golden Girl would you plow first? last?
TIA
...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.
I'm thinking...maybe 2025. Yeah, that sounds about right.
Gol-ly! Is there anything those Google engineers don't know?
Yes, really.
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
"Smaller images on the page mean faster page loads."
Not if decoding them deadlocks the CPU.
"Simplicity in decoding" does not entail any information about the cycles it would eat.
(Posting AC because I'm at work)
That's what web designers need - another image formate that Internet Explorer won't support for years, then will support but support poorly, forcing designers to use annoying hacks to get around the inadequacies of MS's support for the format. Yeah. We really need this.
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/
Google are converting to Webp 'lossless', which their own page shows is not truely lossless and then back to PNG . If I try and further compress googles PNG samples I cannot, however, if I grab the originals and resize using "convert orig.png -resize out.png" then I can equal WebP file sizes in (true lossless) PNG by using 7z deflate...
Sterling work as ever guys...
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.
We need you to copy yet another thing that has been done before, clearly there aren't enough image formats to deal with already.
As a creator of images for the web, I don't see this being implemented into my workflow anytime soon because:
1. It will not be backwards compatible. Will google's format work in IE 6, 7 or other older browsers? Some web developers still have to consider the lowest common denominator. I still don't use png for this reason.
2. How long will it be for Photoshop to build this into the "save for web" options. Until then, I doubt you will find many designers opening up a different program just to save a few K on their graphics.
I am all for the supposed savings with this format, but I guess we will have to wait 5 years to use it... Maybe we'll all have fiber by then and the savings will be irrelevant.
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".
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.
That might only amount to 5-10% reduction of total bandwidth.
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).
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...
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
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.
why not just extend it and screw the committee? why is it nowadays that anytime anybody gets a good idea they have to build a committee or a foundation, or a "working group"
what happens to just doing things and worrying about the adoption later. I mean, if it's truely amazing, people will come onboard because t hey want the benefits also....
why not just make it available, let people build it into the browser if you want, after all, just assign a mime-type, a dll someplace and bingo you're websites can support it, adding image formats or video formats is hardly a chore OR IF IT IS a chore, well, it's 2011 and if adding a new image format to a browser IS a chore, you didn't do a very good job of writing that web browser.
JUST DO IT!!!! stop fucking about, JUST DO IT and worry about bullshit that nobody really cares about afterwards!
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).
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"
As far as I know PNG never had native support for animation - how could they have been so stupid to leave out a basic feature that GIFs obviously have?
Also it has already been said PNG doesn't support EXIF.
PNG deserves to become extinct because of those two obvious mistakes.
yeah ok, so lets all sit around and do nothing for ten years instead, cause thats working out so well isn't it?[/sarcasm]
if you make a bad decision, thats a pity, just put your hands up, correct the mistake get on with your life, stop thinking you have the carry the weight of the world on your shoulders each time you make a decision, thats why we're 10 years later and CSS is still a pile of shit instead of being constantly revised and improved. For example, I _STILL_ cannot vertically align content, it's 2011 right? I mean, guys, make a fucking decision, but stop holding back the entire world because you don't want a make a mistake
fail, but fail fast and then correct fast.
your approach by requiring a years old review means that in 2050, I might be able to vertically align content, my approach means that I'll be able to do it next week and yes some mistakes will happen, but at least if you have an attitude of constantly upgrading the system, by 2050, I'll be doing things you'll never believe are possible.
so if I had to choose between 50 years of ups and downs, or 50 years mostly consisting of waiting around for a bunch of dicks to make a fucking decision, I'd choose my way every time.
yes and you know what, it was a fantastic golden age of browser development, you realise how much development and improvements happened in those years? you wanna think about that the next time you write an ajax handler, if we took the w3c approach, we'd have waited years more to get what we got when microsoft took the "fuck you" attitude and just DID things, got them done, sure they make mistakes but fixed them and then out of nowhere, ajax appeared.....
the old EEE technique is often derided as a negative, but to be honest, at least they improved the system a couple of inches further down the road and yeah mistakes were made, but tbh browser development rocketed forward and if they never did it we'd have had to wait years more for a committee of slow pokes (I'm looking at you w3c!!) to finally full their fat fingers out of their arses and do their fucking job.
you know the situation, where your waiting in a queue and the guy in front of you, is pondering his options, checking what they need, asking stupid questions, etc, etc and you just feel like rushing to the front, shouting it to him, cutting through the crap and telling him what he really needs to hear and giving him the short and sweet that the clerk couldn't do for fear of losing his job? you've seen it on TV if not in real life I'm sure.
Well, thats what I feel like sometimes whenever somebody says "w3c"
Kids bedding . Nw submitter more writes wth news tht Google h added t t WebP image format th ability t losslessly compress images, nd t d wth a substantial reduction n file size compared t th PNG format. Quoting: “Or main focus fr lossless mode h bn n compression density nd simplicity n decoding. Sydney rental properties .
The WebP-lossless encoding is based on transforming the image using several different techniques and then entropy coding of transform parameters and transformed image data. The transforms applied to the image include spatial prediction of pixels, color space transform, using locally emerging palettes, packing multiple pixels into one and alpha replacement. For the entropy coding we use a variant of LZ77 - Huffman coding which uses 2D encoding of distance values and compact sparse values.
(copied from http://code.google.com/speed/webp/docs/webp_lossless_alpha_study.html)
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
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.