Pixels and pixel representations

[Boudewijn Rempt]

I've started working littlecms'ing Krita, and I think that it's useful to
 make a little list of what kinds of classes we currently have for pixels and
 colors (because a single color definition is quite close to a single pixel)
 and what we need to do with them.

 KisPixelRepresentation
 KisPixelRepresentationReadOnly
 KisPixelRepresentationRGB|CMYK|GRAY

Design: These classes contain one QUANTUM* pixel and allow access per
'channel' -- only, a channel must always be a QUANTUM. I think we first need
to get rid of the RGB and other specialisations.

Function: These classes are intended to be used from the iterators. You get
them one by one; it won't mean much memory overhead if we make it slightly
more intelligent

 QUANTUM*

Design: a pointer to a a chunk of memory containing one or more pixels.

Function: efficient bitBlting, conversion, image loading. But also in
conversion code in the color strategies. LittleCMS wants the data it is going
to transform in this format.

 KoColor

Design: a complex class that can transform pixel data using its own
 colorspace conversion algorithms.

Function: in the UI, for instance color selectors. In conversion code in the
color strategies.


I want to propose two classes, KisPixel & KisPixelRO that take the function
of KoColor and KisPixelRepresentation*, for when you want a pixel from the
iterators or define a colour. 

KisPixel & KisPixelRO are Cyrille's KisPixelRepresentation(ReadOnly) with some 
additions, like a separate getter for the alpha channel and for substance 
channels like wetness, grainyness, weight and thichness -- once we implement 
those things. It's no problem to make this class a little heavier, since we 
won't store our pixels as instances of this class, it's just a wrapper for 
code that messes with pixels.

I want to get rid of KoColor, QRgb and QColor -- we can use KisPixel for 
those.

QUANTUM* should become Q_UINT8* and be hidden as much as possible and
certainly never used where you need to get channel values, it's just internal
to the paint device and the colour strategy. KisPixel* can be templated for
various channel types (byte, int, float, double).

We may also need an iterator on paint devices that returns as large a block
of pixels in one iteration as possible, for instance for conversion
operations, loading or saving.

In the meantime, I've integrated most of littlecms, done a colour settings 
dialog, a colour mode conversion plugin and a new new image dialog (but that 
one got lost because I was hacking late yesterday evening and made a 
mistake). And you can move a selection again. I hope to be able to commit 
Saturday at the latest.


--
Boudewijn Rempt | "Geef mij maar zuurtjes."
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/20041202/a8c049b6/attachment.pgp