Q_UINT8 and Pixel

[Boudewijn Rempt]

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