Blend modes

[Casper Boemann]

On Thursday 30 June 2005 13:15, Boudewijn Rempt wrote:
> On Thursday 30 June 2005 12:56, Casper Boemann wrote:
> > During the development phase bloating the colorstrategies with too many
> > blend modes only creates more work for us.
>
> How much of a problem would that be -- I mean, every colorspace already has
> a different set of blend modes. Over, copy & erase are mandatory, but the
> set of other operators is freely extensible. If I add xor to w&s, then
> there's no reason for any other color model to support xor, for instance.
true, I guess I'm a little biased because I recently added a whole new 
argumwent to the ops and I had to do it on all of them. The fewer of the 
exotic blendmodes we have the easier it is do what I did. But I guess this is 
not done every other day so.. forget it

> The real problem is with the functions that do calculations on pixels. If
> an abstract function is added to KisStrategyColorSpace, then all
> colorspaces have to add that function. That hurts development, both for
> you, when you're adding new functionality, and for me, when I'm working on
> W&S, or for Cyrille when he tries to keep grayscale up to date.
yes so true

> > I was thinking that perhabs we should have sub-maintainers of the
> > colormodels. That way the sub-maintainer has the responsibility to always
> > keep the colormodel up to date.
> >
> > And when one updates say the rgb model all one had to do was disable the
> > other models from the makefile. It would then be the responsibility of
> > the sub-maintainer to bring them back in.
>
> I think we had maybe take another route: always add a default
> implementation that converts the colormodel to 8-bit/channel rgba and use
> that
> implementation if the actual color strategy doesn't implement it already.
> That way, all models are always up to date.
I don't think I like that. We could seriously miss that something isn't 
implemented natively.

> Combined with a supportedOps method like the userVisiblecompositeOps
> function, we could implement in filters and so a warning if the user
> attempts to use functionality that will entail a lossy conversion, but it
> will not disable the functionality.
nice concept, perhaps you are right anyway :-)

Still I think we should have sub-maintainers. You already have ws, cyrille has 
gray, what's_his_name (sorry) has yuv, Adrian has rgb16, I could take cmyk

The rgb8 would be common though as this is probably where everything goes 
first.

-- 
best regards / venlig hilsen
Casper Boemann