Color manipulation functions in kdelibs?

[Matthew Woehlke]

Zack Rusin wrote:
> On Wednesday 13 December 2006 14:27, Matthew Woehlke wrote:
>>> but then again no
>>> one blends one pixel with another. People blend drawables. For that we
>>> need a decent image manipulation framework in KDE. For now we don't have
>>> it, so the discussion imho is moot.
>> Actually, it is far from moot. In order to blend images, you have to
>> first be able to blend the pixels in the image. Guess what that means?
>>
>> :-) Everything I have been talking about is the *foundation* of that
> 
> Ah, cool, now I see what you mean. You mean you want to have 
> QPainter::CompositionMode available to composite just QColor instead of a 
> whole drawable. 

Yes, that's it. Glad we are now on the same page. :-)

> The core of your blending appears CompositionMode_Over. 

Mainly (although also needing to do blends in non-RGB color space).

> The whole code is in qdrawhelper[_x86].cpp. I'm not sure whether it really 
> makes sense to export those low-level functions to be used outside QPainter. 
> I'm certainly open to reasons as to why it should be though :) 

No, because there are also accessibility/usability needs here, I still 
think it is best to put the color composing aspects of what we've been 
talking about in kdelibs rather than Qt. The only real overlap I see is 
SourceOver, and even then, only in concept; besides the function is 
trivial ('a*ki + b*k', done on components as needed). Plus I am (now 
;-)) interested in additional modes that AFAICS QPainter does not cover. 
Therefore I don't see any reason why we should tie the two together. But 
I am also open to someone trying to convince me otherwise. :-)

I stand by my original opinion that there should be a kdelibs class 
(meaning, a collection of static member functions) to handle this part.

What about HLS/HSY in QColor? :-)

-- 
Matthew
"unsubscribe me plz!!" -- Newbies