CKMY craziness...

Boudewijn Rempt boud at valdyas.org
Wed Nov 24 09:50:38 CET 2004


On Tuesday 23 November 2004 18:49, Saem Ghani wrote:

> I don't think the pixel needs to know anything except for uint8 * data. 
> From what I understand each layers has a kisimage which stores all the
> actual image data. 

No, a KisImage contains the layers; the layers contain a KisTileMgr.

> Each layer should know what colour strategy it's using. 

That's correct.

>  If it knows that then it can query how many bytes big the data array needs
> to be and that's what will be initialized and used.  And it can understand
> the pixel by way of the colour strategy.  Foreign data, namely foreign
> pixels must be muddled with.  The easiest way might be just passing it in a
> wrapper struct which contains the colour strategy and the data array or
> passing in an extra argument stating the colour strategy.

KisPainter does that job; in the end, KisPainter always takes two paint 
devices (a layer is just a paint device that's gotten snooty about it) and 
merges those. Even the paint tools just boil down to a repeated bitBlt in 
KisPainter.

> I haven't played with pointers heavily in a while, but, I think then it's a
> simple matter of casting the data array to appropriate type array and it
> can be traversed as it should.  The colour strategies will figure it all
> out.

Yes.

> This is basically what I meant when I said we can keep QUANTUM *, with some
> massaging.

I have this irrational dislike of keeping QUANTUM. It makes it look like it's 
a special datatype while for all practical purposes it's just a byte; it's 
not as if we're going to make the size of a QUANTUM the size of a channel.

Except for the places where the code assumes that a channel is a quantum, 
we're already at the point you describe now.

> The problem is that this still requires quite a bit of planning.  The code
> still is rather fuzzy in my head and I have trouble getting comfortable
> with it.
>
> The following could be wrong, but, from what I gather.  The kisImage and

A KisImage -- the class that contains the layers -- should have a default 
color strategy, but at the same time, it should be possible to have layer 
with different color strategies in one image. If only because at one time 
we're going to combine wet layers with rgb pixel layers, and because right 
now I want the selection layer to be a pure alpha paint device.

> kisLayer need to know what colour strategy they are using, which IIRC, they
> already do.  That means they can query how many bytes big their QUANTUM *
> needs to be and the new data type the QUANTUM * needs to be stored as. 

Yes.

We already have KisStrategyColorSpace::depth() which returns the number of 
channels and KisStrategyColorSpace::channels which returns an array of 
ChannelInfo objects (I want this to become a proper vector, by the way). The 
ChannelInfo class describes a single channel:

/**
 * This class gives some basic information about a channel,
 * that is, one of the components that makes up a particular
 * pixel.
 *
 * XXX: refactor name to conform to Krita guidelines.
 */
class ChannelInfo {
        public:
                ChannelInfo() { };
                ChannelInfo( const QString & name, Q_INT32 npos ) : m_name 
(name), m_pos (npos) { };
        public:
                /**
                 * User-friendly name for this channel for presentation 
purposes in the gui
                 */
                inline QString name() const { return m_name; };

                /**
                 * returns the position of the channel in the pixel
                 */
                inline Q_INT32 pos() const { return m_pos; };

                /**
                 * returns the number of bytes this channel takes
                 */
                inline Q_INT32 size() const { return m_size; };

        private:
                QString m_name;
                Q_INT32 m_pos;
                Q_INT32 m_size;
};

Perhaps this class should also be templated or something to make it easy to 
determine the exact datatype of a channel: byte, int, float, double, and I 
think that it makes sense to template the colour strategies for those 
datatypes.

It may also become necessary to template filters that don't use KisPainter, 
but act on the values of the channels directly, such as inversion or 
histogram filters.

(We may also need to make it possible for color strategies query more than 
just the pixels in the tile manager inside a paint device; for some purposes, 
they may need to access the state in the paint device. For instance, the 
selection code is a simple alpha mask with a colour. I can either make the 
colour strategy stateful, adding a colour variable (as in KisColorSpaceAlpha) 
to the colour strategy, or by making it possible for the color strategy to 
query the paint device it's acting on. But this is a different issue.)

> Also the m_channel members need to be templated which should remove the
> excessive casting which kills performance. 

Don't confuse the channels inside KisImage with those in a colour strategy! 
The channels in KisImage are KisChannel's -- an unfinished thing similiar to 
KisMask. Paint devices that do some tricks copied from Photoshop and the 
Gimp, not channels in the R,G,B or C,M,Y and K sense.

> The instantiators of the 
> kisImage and kisLayer will setup the template and also know about the
> colour strategy being used. Lastly we need macros or functions which do
> automatic conversion of foreign data.  So maybe conversion class which can
> convert any colour to CIE (XYZ) and then convert that to any paint type --
> in case of paint types with properties, then we use good default properties
> -- this removes all gamut issues.

We don't need to do that ourselves: littlecms can do that for us. Tonight I 
hope to sketch out a way to use littlecms to do colour conversions.

-- 
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/20041124/d26e06da/attachment.pgp


More information about the kimageshop mailing list