Pixels and pixel representations
boud at valdyas.org
Thu Dec 2 10:27:00 CET 2004
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.
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
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.
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
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
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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20041202/a8c049b6/attachment.pgp
More information about the kimageshop