Color manipulation functions in kdelibs?

[Clarence Dang]

[adding Krita people to CC as I'm sure they have more to say]

I think blending/darken/lighten functions are a good idea.
For RGB functions, start 
reading /trunk/KDE/kdegraphics/kolourpaint/widgets/toolbars/kpcolortoolbar.cpp 
from "roundUp2".  Not particularly stunning implementations but it's 
BSD-licensed.

On Saturday 09 December 2006 08:27, Matthew Woehlke wrote:
> I originally posted this to kde-devel where it apparently went over like
> a lead balloon (judging from how it has been completely ignored). Since
> this would affect kdelibs (I assume), I am re-posting to kde-core-devel
> (if it's off topic, I apologize, and someone please let me know). I'm
> also cross-posting to kde-usability because the usability folks were
> asking for almost exactly this sort of thing, so I'm hoping to get some
> support. :-)
>
> Note: this would be for KDE4 (I wasn't entirely clear on that originally).
>
> Matthew Woehlke wrote:
> > I'm wondering if the following functions or equivalents exist somewhere
> > in either kdebase or kdelibs (my guess would be kdefx). If not, can they
> > be added? know some of these already exist in at least private
> > implementations...
> >
> > ====
> > QColor blendRGB(const QColor& c1, const QColor& c2, double k,
> >                  bool trunc=true)
> > QColor blendHSV(const QColor& c1, const QColor& c2, double k,
> >                  bool trunc=true)
> > QColor blendHLS(const QColor& c1, const QColor& c2, double k,
> >                  bool trunc=true)
> > -
> > Blends between two colors in the specified color space. 'k' is the blend
> > factor, e.g. k=0 gives c1, k=1 gives c2. If 'trunc' is false, allow
> > values < 0 or > 1 (otherwise clamp to [0, 1]), e.g. blendRGB(Qt::gray,
> > Qt::white, -1, false) gives Qt::black, blendHSV(Qt::red, Qt::green, 2.0,
> > false) gives Qt::blue, etc.). If either color is Qt::white or Qt::black,
> > then HLS/HSV treat it as having H and S equal to the other color.
> >
> > ====
> > double blend(double a, double b, double k)
> > -
> > Blends between two values, i.e. 'return a*(1.0-k) + b*k;'. Used
> > internally by the above, or useful to
> >
> > ====
> > void toHLS(const QColor& c, int& h, int&l, int&s, bool true_luma=false)
> > QColor fromHLS(int h, int l, int s, bool true_luma=false)
> > -
> > Convert to/from HLS space (different from HSV space; L=1 means white).
> > If 'true_luma' is true, use 'real' values for L to give pure colors,
> > instead of 0.5 so that the 'true gray value' of any given HLS is equal to
> > L.
> >
> > ====
> > QColor darken(const QColor& c, double k)
> > QColor lighten(const QColor& c, double k)
> > -
> > Similar to blendHLS(c, base, k, false) where base is Qt::black (darken)
> > or Qt::white (lighten). So k=0 gives c, k=1 gives base, k=0.5 gives a
> > color halfway between c and base in HLS space (H,S unaltered), k=-1
> > gives a color twice as far from base as c in HLS space, etc.
> >
> >
> > ...and the above should probably all have Qrgba versions as well.
> >
> > I've used these in a style I wrote, have seen similar implementations
> > elsewhere (in fact, I adapted my toHLS/fromHLS from qt-style-bluecurve),
> > and just copied them into part of KDevelop. For KDE4 it seems like it
> > would be nice for these to be available in a central spot.
>
> Except for toHLS I can provide most of these with little effort. The
> toHLS implementation I currently have is GPL (c) RedHat; if that's a
> problem I have a version I wrote a long time ago that would need some
> work before it could go into KDE.
>
> ...and, as mentioned, the usability folks were specifically asking for
> functions to mix colors, i.e. the blend* family above. Actually, this
> list is incomplete from their perspective because we also need a
> function (or class(*) of functions) to determine the contrast between
> two colors. They are also asking for a function to generate 'possible
> colors' from another color; that is going to be a bit more complex but
> is something that should be looked into.
>
> (* Why a class? Because for accessibility reasons, there may need to be
> as many as three versions; one for 'normal' vision, one for people that
> can't see green, and one for people that can't see color.)