Color manipulation functions in kdelibs?

[Matthew Woehlke]

Cyrille Berger 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 
>> "decent image manipulation framework" that we don't have.
> 
> I feel a litlle bit lost at what you are trying to achieve ? At the
> beginning of the thread, I got the feeling that you wanted blending
> color function for some accessiblity/usuability stuff, but now you are
> speaking of an image manipulation framework, which is a big undertaking.
> As there is more to image manipulation than color blending and
> converting. So please tell us what do you want to achieve so that we can
> find the best solution ?

No, the thread wandered off in that direction. :-)

I am trying to a: steer it back, while b: pointing out that the same 
functions are potentially of more generic usefulness in the 
aforementioned direction. Also c: it would be really cool if we 
accomplished the original goal in a way that allowed blending colors in 
all the ways people might blend pixels (also because that would be 
necessary if we used this as a basis for b, which would be good from a 
code reusability standpoint).

IOW your understanding is correct in that the problem that needs to be 
solved is related to accessiblity/usuability, and also the simple need 
of 'what color is halfway between X and Y'. I currently believe that a 
good implementation is one that could additionally serve as a back-end 
to image manipulation, but that is not one of my goals. Just forward 
thinking.

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