ImageZero 5x faster than WebP

When the initial preview version of ImageZero (IZ) had been announced, many readers were interested in benchmarks against other compression algorithms, such as JPEG-2000 or Google’s new lossless WebP. At that time, however, the WebP software was not yet ready for testing; it was not possible to benchmark the decompression time, because the software could only convert back to PNG (and PNG encoding is known to be slow), and the compression crashed on large photos.

Luckily, the 0.2 version of the WebP tools has been released, and with this, the Lossless Photo Compression Benchmark has been updated to include results for WebP and ImageZero. Here are the most interesting results:

Software / License Size (% of 3.46 GB) Compression Decompression
uncompressed 100.0%
bzip2 -1 (bzip2 License) 56.3% 476 s 218 s
PNG (libpng License) 42.5% 844 s 72 s
ImageZero (BSD) 41.3% 23 s 21 s
JPEG-LS (HP License) 37.4% 107 s 92 s
lossless WebP (BSD) 35.6% 7525 s 110 s
Flic (proprietary) 30.0% 210 s 231 s
Gralic (proprietary) 28.1% 1734 s 1897 s

Fast Lossless Color Image Compression

In the research field of compression, the usual goal is to achieve the best possible compression rate. The best known algorithms, however, are very slow, and sometimes impractical for real-world applications.

When dealing with images, the situation becomes especially worse considering the fact that photo resolutions are ever increasing. Image sizes of 4500×3000 pixels (or more) are not uncommon. Uncompressed, this amounts to 40 megabytes for 24 bits/pixel, and having to wait several seconds for the image to load or save is annoying.

London Bridge (Tower Bridge) : Reflection on the River Thames
Photo by Anirudh Koul at Flickr

JPEG, the de-facto standard for image compression, while still one of the fastest methods available, has one major drawback: it compresses lossy, in other words, whenever the image is saved, some fidelity is lost. For situations where multiple load/save cycles are to be expected, for example in photo manipulation applications, this is inacceptable.

In the recent months, I have been evaluating available lossless image compression algorithms to select one that is fast, but also good in compression efficiency.

Looking at the Lossless Photo Compression Benchmark I was a bit disappointed to find out that PNG, while quite fast in decompression and offering moderate compression rates, is very slow when compressing images.

The JPEG-LS format, being significantly faster at compression compared to PNG, and even offering improved compression rates of about 15%, seemed a good choice at first. It has, however, several drawbacks: Not only is it slower than PNG in decompression, but HP also has a patent on the used context modeling. No-Go.

What does a programmer do, when he is not satisfied with what is available? Right, he re-invents the world, only to make it better: Last week, I released the initial version of ImageZero (iz, pronounced “easy”), a high-performance lossless RGB photo codec.

Being twice as fast as PNG when decompressing (and more than 20 times faster when compressing) it achieves compression ratios that are near or better than PNG for natural photos, sometimes even better than JPEG-LS for very high quality photos. ImageZero is not intended for grayscale or artificial images, but I may improve the algorithms for those image types.

Method File Size Compression Decompression
uncompressed 46380 KB
JLS 14984 KB 6.6 s 7.3 s
PNG 16256 KB 42.4 s 2.4 s
IZ 15496 KB 1.2 s 1.3 s
Results for the full resolution “London Bridge” photo (4507×3512 pixels)

The used algorithm is really easy: the per-pixel compression and decompression is done without any branches (except for a single branch in the bit coder), so that on today’s super scalar CPUs it can be executed very fast.

Possible uses include:
– image/thumbnail databases
– backing store for image processing apps
– future icon format

If you are interested, please help shaping the library API and file format for .iz files. We can use the kde-imaging mailing list for discussion.