[Kde-imaging] Lossless image compression

[Christoph Feck]

On Monday 06 February 2012 16:35:31 Boudewijn Rempt wrote:
> On Mon, 6 Feb 2012, Christoph Feck wrote:
> > 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.
> 
> Yes, I was thinking about that and posed it as possible usecase
> on lwn.net. The thing is, Krita needs to compress the files it
> generates or they become too big, but the compression method we
> use right now is too slow. But it's not too slow because of the
> algorithm itself, it's too slow because krita internally
> interleaves the color data (RGBRGBRGB) instead of storing it
> planar (RRRGGGBBB). The de-interleaving is what is very slow.

Good, in fact IZ expects packed pixels, i.e. all pixel components 
accessible via a single pointer. What I am not sure about is the 
pointer advance from one pixel to the next. Currently, IZ expects that 
the pointer difference between neighboring pixels is constant in both 
dimensions (one ptrdiff_t for each). Would Krita require more advanced 
iterators?

> So, for Krita we'd need something that has a decent compression
> ration and can handle interleaved colordata. A pixel in Krita can
> have any number of channels, 8 bit int, 16 bit int, 16 bit float,
> 32 bit float.
> 

IZ cannot handle float data, because it compresses by discarding 
leading zero bits of pixel differences, but I guess it would be 
possible to fall back to existing code in case of non-int data, right?

From your experience, how big is the ratio of float files vs. int 
files? If most people are using floating point color spaces, it would 
not make much sense to optimize the integer color spaces.

Regarding the number of channels, you would need a custom pixel 
template class for each color depth you are going to use (and ideally 
for each color space, to help compression efficiency in the cases 
where color components have a high correlation, as in RGB), otherwise 
it would be slower to handle a "generic" case, where you just say that 
a pixel consists of "n" components, and code for loops would have to 
be generated.