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.
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; }
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?
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.
come on dude. the oblig xkcd should at least have the oblig "a" tag around it.
CSS3 will soon eliminate the need for rounded corner images and gradient backgrounds
There never was any need for rounded corners and gradient backgrounds.
Give me Classic Slashdot or give me death!
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.)
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.
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
The one that still has a pulse.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.