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."
Because that requires a committee and would take 10x as long, if ever, to get done.
Yes, it's in TFA url and title. :)
... because Chrome is STILL NOT color managed.
You don't have to pay for a JPEG license, try again.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
TIFF exists. The world doesn't need another file format where most clients don't implement the full standard and the user can never expect a file in that format to be reliably readable everywhere.
But extensions are good for adding information, not removing it. You could probably implement whatever compression enhancements Google made to WebP in PNG through extensions, but probably not in a way that makes old versions of libpng still produce usable results while still having a reduced filesize. At which point it doesn't really matter if you add it to WebP or PNG, the backward compatibility benefit of PNG extensions can't be exploited either way
If it truly is a significant innovation, it should sail through the standards approval process as a recognized extension.
Which is not actually that helpful, because then you have tons of PNG-capable applications that can't read PNGs. TIFF used to be this way, where TIFF actually means it can be compressed like ten different ways and support was very mixed. If you have a significant new non-backwards compatible format, just releasing it as a new format is maybe just as easy.
Live today, because you never know what tomorrow brings
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.
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
Recycling a name for a new incompatible format is a terrible idea. If I have a png image and software that supports pngs, I should be able to read that image, period.
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
JPEG XR produces images similar to JPEG-2000 while having complexity similar to JPEG, supports transparencies, requires support for lossless compression (unlike JPEG) since lossless is just a quantizer setting, and it's already supported by IE9.
That last bit is probably the most important part. IE's marketshare is shrinking, but it's still big enough that any format it doesn't support is unlikely to see widespread support as the only format available for a site. I doubt IE will ever support WebP, and as such, no website will ever really be able to use WebP. Not unless they do browser detection, and most sites won't bother with multiple image compression formats, they're going to pick the best common one they can, which is currently PNG or JPEG.
Remember PNG alpha support... Until IE supported it, nobody really used it. Once IE did, it became mainstream.
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.
Which is not actually that helpful, because then you have tons of PNG-capable applications that can't read PNGs. TIFF used to be this way, where TIFF actually means it can be compressed like ten different ways and support was very mixed.
Only ten different ways? Back in the early 90s I was creating TIFF files that I doubt anyone can display these days; we had our own TIFF tags assigned and could compress files however we wanted to.
This is why TIFF was:
1. Very useful for app developers.
2. A total disaster for interoperability.
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.
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 fact the encoding is behind the scenes doesn't matter. In a decade html5 video will be defined by webm because no one wants to license h.264 for encoding products.
An that goes double for .avi files!
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
It's OK, nobody uses JPEG 2000 anyway.
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.
Why would he? The standards body that approved it didn't.
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.)