colorstrategy independence

[Boudewijn Rempt]

On Sunday 13 March 2005 16:02, Casper Boemann wrote:

That was quick -- you sent this as I was sending a mail asking you for this...

> 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 :-(.

> Almost every filter and tool,, as well as some other places, assume RGB. We
> have colorstrategy class in place, but we don't use it as much as we
> should.
>
> Colorstrategy independence consists of:
> - number of color channel independence (we are halfway there)
> - per channel type independence (nowhere near ready)
> - per channel size independence (nowhere near ready)
> - per channel interpretation independence (not even begun)
>
> What this means is that CMYK,LAB,HSV,XYZ hasn't got a chance of working
> before we do some serious work.
>
> Take plugins as an example. In one place we compute the brightness as:
> .17*ch[0]+0.35*ch[1]+ 0.5*ch[2]
>
> This is true for RGB, but not for any other colorstrategy. If we allow a
> lot of new plugins to be developed in the same way, we'd never be
> colorstrategy independent.
>
> Even if we use KisQuantum this would never be right. Sure we would overcome
> the problem of per channel size and type independence, but the
> interpretation would be all wrong.

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.

> 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.

> 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.

-- 
Boudewijn Rempt 
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/20050313/88c0b007/attachment.pgp