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."
Yes, it's in TFA url and title. :)
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.
One of the key design features of PNG was that any PNG should be able to be read by any decoder. That is why PNG has relatively few options on how the core data is encoded*
Adding optional stuff is ok (unless it's animation......) but if you want to make a key change to the core of the format I suspect the PNG guys would tell you to go make your own format based on PNG but with it's own specification, file extension and "magic number" (as was done for MNG, and JNG).
* a handful of filter types all of which are easy to implement, one compression algorith, one byte order standard, 15 allowed color/bitdepth combintions (the majority of which represent very comon combinations and all of which can be easilly mapped to 24-bit RGB).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
>"Last month we announced WebP support for animation, ICC profile, XMP metadata and tiling."
I assume thats a 'yes'.
Here you go, boy.
Right now JPEG org promises that you will not be sued for implementing the basic JPEG 2000.
All hope abandon ye who enter here.
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.
and it is the only royalty free web video codec.
Except Theora. Though from what I've seen WebM has the edge in video quality.
I assume this would be useful for correcting for differences in displays?
Not just displays, cameras, scanners and printers also use ICC profiles to compensate for the fact that they all capture and reproduce colours slightly differently. This is a good place to read some basics.
Blank until
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.)
The original pngquant was quite bad indeed (it did support alpha, but poorly). It had lots quality trade-offs for MS-DOS era machines.
The modern rewrite is much better in terms of quality and it's especially tuned for good alpha channel support.
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