What to do about KColor?

[Ingo Klöcker]

On Monday 28 May 2007 18:10, Thomas Zander wrote:
> On Monday 28 May 2007 16:37:37 Ingo Klöcker wrote:
> > > I expect people to adjust to the new concepts over the duration
> > > of the KDE4 lifetime and when they do, then it becomes weird when
> > > there are two conflicting ways to set the blending amount.
> >
> > Why conflicting? If I blend two colors with different alpha values
> > a1 and a2 then I'd expect to get the blended color with alpha value
> > (a1+a2)/2 ( or (1-r) a1 + r a2 in the more general case ). Again,
> > that's what I as email application developer (and maybe also as
> > mathematician) would expect. I don't want to study color theory to
> > understand what a certain method I want to use actually does. No, I
> > want the method to do what I expect it to do. But I guess just as
> > in application usability you'll get ten different expectations if
> > you ask ten different people.
>
> We are talking about slightly different things here :)
>
> I agree with what you wrote above;  blending of 2 colors means take
> the average (and that is exactly what the current one does).
>
> The request you wrote in the previous email is to change the blend
> method to include a double on how much blending is done.
> So, instead of using the exact difference between the two you are
> able to state how strong the second color is applied to the first in
> returning the result.
> And that makes sense in old colors, sure.  Where is starts to get a
> bit weird is if you have a color A and a color B where color B has an
> alpha of 50% and you call the blendColor with an additional
> parameter 'strength' that you also set to 50%.
> The question that different people will probably answer differently
> is how strong the second color will have to be applied. Is it 50%? Or
> is it 25% (50% of the 50% that the color is already transparent). Or
> even something different based on color theory which is not perfectly
> linear...

Well, I'd expect the color values to be blended without taking the alpha 
values of the two colors into account. The alpha values would be 
blended independently.

> So, that's why I stated its conflicting.
>
> Hope that makes it clearer :)

Okay. For me there was no conflict because I meant to treat the color 
values and the alpha values separately. Obviously, I didn't make this 
clear. :-)

> > Whoever adds code to our core libraries should be aware of the fact
> > that this functionality will be used by people who are not
> > necessarily experts in the domain of this functionality.
> > Functionality that does require more than a slight understanding of
> > the matter and some common sense does IMO not belong into our core
> > libraries but into some special purpose libraries, like say
> > Pigment. So please keep the color related stuff in kdelibs dead
> > simple and easily understandable for idiots like me. Thanks!
>
> Fully agreed, and I was under the impression that this new method
> that was committed this morning does exactly that.
> It blends 2 colors. Nothing more, nothing less.

It doesn't blend 2 colors. If it would truly blend 2 colors then the 
alpha channel of the result would be some (linear) combination of the 
alpha values of the original colors. But this method always returns an 
opaque color. The alpha value of the second color is taken into 
account, but the alpha value of the first color isn't. This is 
absolutely illogical and unintuitive. In particular, I would expect 
this method to be commutative, i.e.
  blendColor( c1, c2 ) == blendColor( c2, c1 )
for all values of c1 and c2.

If one really wants to abuse the alpha channel for specifying the 
blending ratio just in order to safe one parameter (which would be way 
more intuitive) then I would expect the ratio of the two alpha values 
to determine the blending ratio, i.e.

    QImage img(1, 1, QImage::Format_ARGB32_Premultiplied);
    QPainter p(&img);
    QColor start = one;
    start.setAlpha(255); // opaque
    p.fillRect(0, 0, 1, 1, start);
    p.setCompositionMode(comp);
    QColor second = two;
    if ( one.alphaF() + two.alphaF() > 0 ) {
      second.setAlphaF( two.alphaF() / ( one.alphaF() + 
two.alphaF() ) );
    }
    else {
      second.setAlphaF( 0.5 );
    }
    p.fillRect(0, 0, 1, 1, second);
    p.end();
    return img.pixel(0, 0);

This way blending two opaque colors would yield the expected (by me and 
it seems also by Andreas) result. In my opinion this would improve the 
usability of the blendColor() method.

And if we also want to get an appropriate alpha value then we can simply 
replace the last line by
  QColor result = img.pixel( 0, 0 );
  result.setAlphaF( 0.5 * ( one.alphaF() + two.alphaF() ) );
  return result;

Now that we would something I can really live with.

What do you think?

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070528/d096c454/attachment.sig>