|
|
|
@ -23,7 +23,7 @@ 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 DImg.
|
|
|
|
|
it doesn't aim to be a complete imaging library; it uses QImage for
|
|
|
|
|
it doesn't aim to be a complete imaging library; it uses TQImage for
|
|
|
|
|
rendering and for loading files which are not supported natively by it.
|
|
|
|
|
some of the working/planned features:
|
|
|
|
|
|
|
|
|
@ -53,11 +53,11 @@ 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)
|
|
|
|
|
|
|
|
|
|
* Rendering to Pixmap: using QImage/QPixmap. (see above for rendering of
|
|
|
|
|
* Rendering to Pixmap: using TQImage/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
|
|
|
|
|
* Pixel format: the pixel format is different from TQImage/Imlib2 pixel
|
|
|
|
|
format. In TQImage/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 DImg, the pixel data is stored as unsigned char.
|
|
|
|
|
the color layout is B,G,R,A (blue, green, red, alpha)
|
|
|
|
@ -89,7 +89,7 @@ for (int i=0; i<image.width()*image.height(); i++)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
means is that the pixel format is different from that of TQImage for big
|
|
|
|
|
endian machines. Functions are provided if you want to get a copy of the
|
|
|
|
|
DImg as a QImage.
|
|
|
|
|
DImg as a TQImage.
|
|
|
|
|
|
|
|
|
|