Lossless image compression

Christoph Feck christoph at maxiom.de
Mon Feb 6 15:10:21 UTC 2012


you might have already read [1] of my current project "IZ" [2], aiming 
for fast lossless image compression for photos.

Performance wise, IZ lies in the "sweet spot" where it actually 
improves loading time (because of less disk transfers), instead of 
slowing it down (because of the slow compression). It is intended to 
replace code where uncompressed data or only simple run-length 
encoding was used because of speed constraints.

The library currently only handles 8 bit RGB, mostly because of the 
lack of a sufficiently large set of sample images which use 16 bit 
and/or alpha channel. Pointers appreciated.

I plan to use IZ for a future KDE icon/thumbnail database project, but 
I guess there might be several other uses in KDE, for example in 
digiKam as a format to store its thumbnails, or as the swap 
compression for Krita. It has even been suggested to use it in 
OpenRaster format, or in the Krita native file format.

Before it can be useful, however, I need input about the API design. 
The plan is to have a low-level C++ template based compression 
library, allowing to code raw 8/16 bit RGB(A) pixel image data from/to 
memory, where the layout of the pixels (RGB vs. BGR, ARGB vs. RGBA, 
etc.) and the resulting code stream (bytes vs. machine words) can be 
customized via custom templates or template arguments.

I am aware that it should allow tiling/striping (i.e. coding image 
parts separately or seamlessly). Which other features are needed to be 
useful? For the stream container or other meta data, I think it would 
be best to have those handled by the application.

(CC'ing krita list, please reply to kde-imaging, too)

[1] http://kdepepo.wordpress.com/2012/01/30/fast-lossless-color-image-
[2] https://gitorious.org/imagezero

More information about the kimageshop mailing list