colorstrategy independence

[Casper Boemann]

On Sunday 13 March 2005 16:19, Boudewijn Rempt wrote:
> That was quick -- you sent this as I was sending a mail asking you for
> this...
Call me a mind reader :)

> > At the moment we are darting out a wrong path regarding colorstrategy
> > independence.
>
> I'd say we're moving in the right direction. Of course, even CMYK doesn't
> display correctly at the moment -- there are still basic problems with
> converting colors as selected in the GUI to native colors :-(.
Yes and no, it's not like the filters already written are a total waste of 
effort. We just need to move some of the contents to colorstrategies. But 
still its a lot of work.

> A cogent argument -- and I agree with you, but not completely...  Have a
> KisQuantum (sorry -- in my previous mail I confused KisQuantum with
> KisChannel -- but KisChannel would be a better name, I guess) that offers
> basic math operations. For every channel data type have a subclass. The
> operations should include (among others)
>
> invert
> average
> sum
> substract
> multiply
> upscale
> downscale
>
> etc.
Yes, as I said it is a way to overcome (float,double,int8,int16) ambiguity.

However, is invert of hue the same as invert of Y and can it even be done 
without knowing the other channels ?

And is hue represented in double from 0-1 or 0-360 or 0-2pi

We cannot do this in a way that is generic. So colorstrategy is needed for 
interpretation independence.

To overcome type and size independence I'd personally prefer not to use 
KisQuantum at all, and move to templates .If say we need an int8 and int16 
version of RGB. That would save a lot of virtual calls. But KisQuantum is 
surely a (even prettier) way to do it - just not as efficient.

KisQuantum is though needed if say filters need to do any work on channels in 
a direct (and interpretation dependent) way. I don't think we need or want to 
do that, but I'm not sure and until that is tested in real life I think that 
we should keep KisQuantum just to be on the safe side.

On the other hand the existence of KisQuantum might be an invitation to do 
non-colorstrategy independent work, and that is a problem.

> > In HSV the brighness would actually be the 3'rd channel and in XYZ it
> > would be the 2.nd channel. Oh and even then the brigthness wouldn't be
> > perceptually the same.
> >
> > In my view the only way to be independent is for every colorstrategy to
> > provide a toolkit of pixel mangling functions, that the filter and tools
> > can use to do their work. Say a brightness_halfer_filter:
> >
> > bright = colorstrategy->brightness(pixel);
> > pixel = colorspace->setBrightness(pixel, bright/2);
>
> Very true -- but I'd prefer this to be a little more generic. Not just
> bluntly an interface requirement for all color strategies, but a way to
> query a color strategy for the operations it supports (just like we should
> be able to query the color strategy for the composite ops it supports and
> are able to query the color strategy for the types of channel it has --
> take a look at he rudmimentary wet & sticky model for a few weird types of
> channels). If a certain color strategy doesn't include a capability, we
> should do a conversion to a color strategy that does support the capability
> and then convert back.
I agree completely. The two functions I wrote, were merely an example. Not an 
actual proposal for an API. Still an API should preferably be as common as 
possible.

> > That way it wouldn't matter what the colorstrategy is. The filter would
> > always work.
>
> Some filters wouldn't have much to do except create an iterator and call
> the color strategy :-). And if we would do things stl-like, we'd create the
> iterators and feed the iterators to the filter, instead of letting the
> filter create the iterator.
Yes, and no. To some extent we can do this but too much or we would bloat the 
colorstrategies.

-- 
best regards / venlig hilsen
Casper Boemann