[Kde-imaging] Lossless image compression

[Boudewijn Rempt]

On Wednesday 08 February 2012 Feb, Christoph Feck wrote:
> 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. 

Great!

> 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?

No, I don't think so. All pixels are always the same size in Krita as well.

> 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?

Sure!

> 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.

Most artists really use either 8 bit rgba or 16 bit integer rgba; it'll be really worth it to optimize for them.


> 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.

That doesn't sound at all bad!

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl