[Kde-imaging] Lossless image compression
caulier.gilles at gmail.com
Tue Feb 7 12:33:49 UTC 2012
2012/2/6 Boudewijn Rempt <boud at valdyas.org>:
> On Mon, 6 Feb 2012, Christoph Feck wrote:
>> you might have already read  of my current project "IZ" , 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.
To use it in digiKam, as photo archiving purpose, 16 bits must be
supported, alpha channel is not mandatory but prefered, but the MOST
important is metadata support, to be able to store Exif, IPTC, and XMP
bytearray. Else, this format will be never used in photography world.
I patched myself PGF library in this way. in digiKam we use this
format for archiving purpose and to store thumbnails in DB (wavelets
I also patched Exiv2 shared lib to be able to play with PGF metadata.
This very important point.
More information about the kimageshop