Lossless image compression

[Boudewijn Rempt]

On Mon, 6 Feb 2012, Christoph Feck wrote:

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

Many cameras support 16 bit raw pictures; maybe Gilles has a database
of useful images?B

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

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.

For openraster, well that is defined to use png right now, 8 or 16
bit integer with alpha channel.

> 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)
>
> References:
> [1] http://kdepepo.wordpress.com/2012/01/30/fast-lossless-color-image-
> compression/
> [2] https://gitorious.org/imagezero
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>