[Digikam-devel] Imaging Library

[Gilles Caulier]

Le Dimanche 19 Juin 2005 11:15 PM, Renchi Raju a écrit :
> as you all know, we have been using imlib2 library for the 0.7 series. we
> have had a fairly large number of bugreports because of imlib2 (not
> imlib2's fault, but because of kdelibs's handling of ltdl). In addition,
> some imlib2 bugreports I reported to upstream have gone unfixed for long
> time now.

Yes, I have seen that...


>
> Also, we need to think about 16bit imaging support. this won't come from
> imlib2 and neither from qt. with qt4 there was hope of 16bit image
> support, but trolltech has made it clear that imaging apps forms only 0.1%
> of their customer base and they are not interested in providing custom
> support for them. so the only solution  I see (without depending on
> imagemagick) is to roll our own library.
>
> i have been working on a imaging library for digikam, its called DImage.
> it doesn't aim to be a complete imaging library; it uses QImage for
> rendering and for loading files which are not supported natively by it.

Wonderfull !

> some of the working/planned features:
>
> * Native Image Loaders, for some imageformats which are of interest to
> us: JPEG (complete), TIFF (a rudimentary one currently), 

TIF is important (My film scanner can provide only TIFF files in 16 
bits/color/pixels)

> PNG (planned) 

PNG is very important. I have over 10.000 photographs in this format to my 
hosts computer.

> , PPM 
> (planned). for the rest qt's qimage is used.
>
> * Metadata preservation: when a file is loaded, its metadata like XMP,
> IPTC, EXIF, JFIF are read and held in memory. now when you save back the
> file to the original file or to a different file, the metadata is
> automatically written (How, we have been handling it currently with
> imlib2 is on saving a file: we save the file to a temporary file, reread
> the exif info from the original file and then write to a second temporary
> file.)

Waou ! I'm very impressionned. Have you used a dedicaced library to drive XMP 
metadata ?

>
> * Explicitly Shared Container format (see qt docs): this is necessary for
> performance reasons.

I don't know ESC. I will take a look. 

>
> * 8bit and 16bit support: if the file format is 16 bit, it will load up
> the image in 16bit format (currently only 16bit tiff support) and all
> operations are done in 16 bit format, except when the rendering to screen
> is done, when its converted on the fly to a temporary 8bit image and then
> rendered.

Nice ! Digikam will be the ultimate _Photograph_ management program !

>
> * Basic image manipulation: rotate, flip, color modifications, crop,
> scale (this has been ported from Imlib2 - originally ported by Mosfet, I
> added 16 bit scaling support and support for scaling of only a section of
> the image)

Mosfet have give me a tarball of the future KImageEffect version 2 
implementation. Take a look here :

http://digikam3rdparty.free.fr/libkimageeffect2.tar.bz2


>
> * Rendering to Pixmap: using QImage/QPixmap. (see above for rendering of
> 16bit images).
>
> * Pixel format: the pixel format is different from QImage/Imlib2 pixel
> format. In QImage/Imlib2 the pixel data is stored as unsigned ints and to
> access the individual colors you need to use bit-shifting to ensure
> endian correctness. in DImage, the pixel data is stored as unsigned char.
> the color layout is B,G,R,A (blue, green, red, alpha)
>
> for 8bit images: you can access individual color components like this:
>
> uchar* pixels = image.bits();
> for (int i=0; i<image.width()*image.height(); i++)
> {
>    pixel[0] // blue
>    pixel[1] // green
>    pixel[2] // red
>    pixel[3] // alpha
>
>    pixel += 4; // go to next pixel
> }
>
> and for 16bit images:
>
> ushort* pixels = (ushort*)image.bits();
> for (int i=0; i<image.width()*image.height(); i++)
> {
>    pixel[0] // blue
>    pixel[1] // green
>    pixel[2] // red
>    pixel[3] // alpha
>
>    pixel += 4; // go to next pixel
> }
>
> the above is true for both big and little endian platforms. What this also
> means is that the pixel format is different from that of QImage for big
> endian machines. Functions are provided if you want to get a copy of the
> DImage as a QImage.
>

When DImage will be include in digiKam, we need to adapt image editor plugin 
parts. Let's me hear when you want to do it !


> ---------------------------------------------------------------------------
>
> I have provided a tarball for you to play with, if anyone is interested:
> http://pooh.tam.uiuc.edu/digikam/canvas_dimage_16bit.tar.bz2


SUre, I'm _VERY_ interressed !!!!! (:=)

>
> * Compiling:
>
> # tar jxvf canvas_dimage_16bit.tar.bz2
> # cd canvas_dimage_16bit
> # ./configure
> # make
>
>
> * Running viewer:
>
> to run a app which loads and displays one 16bit tiff, one 8bit jpeg
> and one 8bit transparent png (if someone wants to verify that the tiff
> image is indeed 16bit, try loading it up in gimp and see the warning
> message)
>
> # cd app
> # ./canvas
> (use:
>   +,- to zoom;
>   1,2,3 to rotate 90,180,270;
>   h,v to flip horizontal,vertical;
>   g,shift-g,b,shift-b,c,shift-c to change gamma, brightness, contrast)
>
> * Running benchmark:
>
> A small benchmark utility is provided to compare DImage, QImage, Imlib2
> performance for loading, scaling and rendering:
>
> # cd ../benchmark
> # ./benchmark
>

Well, i will take a big coffee and look your code. Thanks in advance for this 
job Renchi !

-- 
Gilles