Color manipulation functions in kdelibs?

[Zack Rusin]

On Thursday 14 December 2006 11:54, Matthew Woehlke wrote:
> Because you can't do a perceptually correct lighten/darken in RGB space
> (or HSV space, either). 

Yes, you can't do a lot of things in each of the color spaces. It's not about 
what you can do perfectly with one of them. Adding a whole bunch of methods 
to kdelibs to achieve color perfection is absolutely silly. Color-spaces are 
a mess on our current workstations, web-formats use non-linear colorspaces 
all the time which already completely screws color precision. 

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

That's a purely semantically problem. I don't see any problem with adding 
lightHLS, darkHLS or ever changing those two methods in QColor itself. It's a 
trivial patch. 

> > 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)? 

More fluid in which way? 

> I thought we were agreeing here?

Really? I'm sure I never, ever supported duplicating functionality from Qt in 
KDE when a trivial thing was missing in Qt. 

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

Great. We agree that since they're useless now we won't be adding them.

> Because I want HLS-true lighten/darken, which are also distinct from
> what QPainter does

We do? Then surely we can accept that feature request and expose those in Qt.

> Did you look at alphaBlendColors in Plastik? 

Yeah, don't see a problem with it.

> Did you look at the KDevelop patch (now checked in) that I referenced? 

Nope, if you can show me the diff that'd be great. 

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

Nope, I find it silly when people split the same discussion on the same list. 
I did go over it now and don't see absolutely anything in it that would force 
those methods in kdelibs and not in Qt or that would even imply their 
incredible importance. 

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

Two good would be enough to have me expose blend methods, I think I'm 
convinced that I should just make light/dark from QColor do proper 
lighting/darkening of a color. I'm assuming the latter would be enough to 
just end the discussion, right?

> As many styles as are out there on kde-look, how many /more/ examples do
> you think exist?

I'm not really convinced that any of them need it. It looks more like a case 
of "Y said that it has to be done like this", but like I said I'm fine with 
fixing light/dark in QColor to behave like you want.

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

Yeah, maybe you're right. It's simply that no one asked for everyone just went 
ahead and implemented their stuff. If that's what people want then I don't 
think anyone minds having all those people keep their code and if we agree 
that KDE actually needs it and it's a core functionality, them bam in Qt it 
goes.

z