Color manipulation functions in kdelibs?

[Matthew Woehlke]

Zack Rusin wrote:
> On Wednesday 13 December 2006 16:15, Matthew Woehlke wrote:
>>> The core of your blending appears CompositionMode_Over.
>> Mainly (although also needing to do blends in non-RGB color space).
> 
> Interesting. Why?

Because you can't do a perceptually correct lighten/darken in RGB space 
(or HSV space, either). It has to be done in HLS/HSY space (HSY would be 
the most correct, but HLS is still a major improvement over RGB or HSV). 
Why? Consider 'dark red'. 33% lighter than 'dark red' should be 'pure 
red', but QColor::light will wash the color out towards gray. If you 
used HSV space instead, you get stuck when you hit V-1.0, and the only 
way to handle things "properly" is to interpolate along a spline fitted 
through white, black, and the color being modified. I don't know about 
you, but I'd as soon not have to do that.

In HLS/HSY space, you bump up L/Y and you're done. Correct result and all.

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

Because I expect this to need to be more fluid that Qt would allow 
(and/or more fluid than users would appreciate if it meant every minor 
KDE upgrade required updating Qt as well)? I thought we were agreeing here?

>>  Plus I am (now ;-)) interested in additional modes that AFAICS QPainter 
>>  does not cover. 
> 
> Why? 

Because I think they would be useful? :-) Because I don't believe that 
blend should be limited to RGB color space? (Think about gradients; 
wanting an HSV gradient instead of an RGB gradient is relatively 
common.) Because that image manipulation framework that doesn't exist 
will need them? Because /having/ them will open new creative/artistic 
possibilities that maybe neither of us is thinking of? (Especially since 
the idea is biased towards allowing requests; another reason to go 
kdelibs instead of Qt.)

Because I want HLS-true lighten/darken, which are also distinct from 
what QPainter does (although they are really specific invocations of 
blend in HLS space).

>> I stand by my original opinion that there should be a kdelibs class
>> (meaning, a collection of static member functions) to handle this part.
> 
> I think the core problem here is that I (and others) just don't see the use 
> cases. So can you show me the use cases - code that uses this in KDE that 
> makes it clear that this needs to be in kdelibs and not Qt and needs 
> additional color spaces (both the application code and autotests).

Did you look at alphaBlendColors in Plastik? Did you look at the 
KDevelop patch (now checked in) that I referenced? Have you read the 
thread on kde-usability about how we need to provide means to generate 
'accessible' colors that fit in the user's current color scheme? Have 
you looked at bluecurve-style (in redhat-artwork) that /does/ use HLS 
conversions? Those (except KDevelop) are all examples that /other 
people/ wrote. And, again, those are just the ones I know of. That's at 
least three re-inventions of the wheel (not counting the style I wrote 
as number four), and that's without /trying/ to find examples. How many 
do I need to find to convince you that this should be available in a 
major library so that people don't have to keep re-implementing it? As 
many styles as are out there on kde-look, how many /more/ examples do 
you think exist?

This seems to me like such a /basic/ (and trivial) functionality that I 
don't understand why it doesn't exist yet in a standard library.

>> What about HLS/HSY in QColor? :-)
> 
> Lets do the above before we talk about this.

I'm going to reply to this separately, but will remind you that if Qt 
does not have HLS/HSY color space, then there is no way for me to 
implement the lighten/darken I want to use, and so I have to implement 
yet another stand-alone HLS conversion suite. Reinventing the wheel yet 
again.

-- 
Matthew
What? This signature /again/?