CKMY craziness...

[Saem Ghani]

On Tuesday 23 November 2004 03:11, Boudewijn Rempt wrote:
> On Tuesday 23 November 2004 12:06, Cyrille Berger wrote:
> > On Tuesday 23 November 2004 11:26, you wrote:
> > > And we don't need a different class to store the definition of a color
> > > or a pixel; they are the same.
> >
> > That was my point ;)
> >
> > > What I was thinking was a simple class containing
> > > a point to enough bytes to repesent a color and a pointer to a color
> > > strategy;
> >
> > I am not sure, it would be very memory consuming to have a pointer to a
> > strategy with the pixel.
>
> Hm. Maybe colors and pixels must be two different things after all --
> because sometimes you need to pass, e.g., a fill color to a painter. In
> that case, the fill painter needs to know in what color model the color is
> defined.
>
> If you mere get pixels from paint devices to manipulate them and put them
> back, you don't need the colour model in every pixel, in that case you know
> which color model the paint device has. But in those cases a simple pointer
> to bytes is enough; the color model can handle the conversion to channels
> and things like that.
>
> > And I don't think that is useful to have
> > different color strategies on a single paint device.
>
> That's not what I meant -- I mean, littlecms defines several types of cmyk,
> rgb or grayscale. We'd ideally want all cmyk types handled by our color
> strategies for compositing can easy access to conversion.

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.  Each layer should know what colour strategy it's using.  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.

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.

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

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 
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.  Also 
the m_channel members need to be templated which should remove the excessive 
casting which kills performance.  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.

So, corrections please!