Q_UINT8 and Pixel
Boudewijn Rempt
boud at valdyas.org
Fri Mar 10 17:28:52 CET 2006
On Friday 10 March 2006 17:11, Leonardo Giordani wrote:
> > We do that because Krita itself doesn't know about that (or any) kind of
> > Pixel. All it knows about is raw, uninterpreted data, which it sees as a
> > big Q_UINT8 array. Krita's core really doesn't (need to) care about what
> > the individual colorspaces do with it. It is up to the colorspaces to
> > cast the data Krita gives to them, to actual things they know about, like
> > in this case, a Pixel.
>
> Thanks Casper and Bart. If I understood you both say that Krita, while
> _vidualizing_ data manages them as UINT8, but when _working_ with them uses
> a colorspace and thus the Pixel object defined into this latter.
>
> So this is a conversion between the actual colorspace to the RGB of the
> monitor, right?
No, it has nothing to do with this. It's like this: krita has a semi-efficient
datamanager that stores pixel data, but doesn't know about the way that data
is divided into pixels (or rather, it does know how many bytes a pixel is,
but not how the pixel is divided into channels). Whenever you want to mess
with pixels, say, blend a row of pixels with another, you iterate over the
source and destination pixels in Q_UINT8* form. You pass pointers to
stretches of Q_UINT8* to the colorspace, who knows how to do the blending
internally.
The conversion between colospaces is done through the colorspaces, too, of
course, whether you convert cmyk to lab, or anything to rgb for display.
--
Boudewijn Rempt
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20060310/92fc37b1/attachment.pgp
More information about the kimageshop
mailing list