[Kde-imaging] Lossless image compression
boud at valdyas.org
Wed Feb 8 13:24:26 UTC 2012
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.
> 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
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?
> 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!
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
More information about the kimageshop