Color manipulation functions in kdelibs?

[Matthew Woehlke]

Zack Rusin wrote:
> On Wednesday 13 December 2006 11:54, Matthew Woehlke wrote:
>> Eh? Qcolor::dark and QColor::light do not work the way I need them to,
> 
> heh, well, lets figure out how to make them work the "way you need them to".

I already wrote working versions...

>> HDR is not supported, there is no HLS or HSY support at all, and if
> 
> HLS and HSY isn't really necessary for any kind of desktop usage, is it? i'm 
> just wondering whether there is an actual need for it or whether it's just 
> something that would be cool to have. 

...that are based on HLS color space. IOW, I need HLS/HSY support to 
implement them.

Are they necessary for desktop usage? No, but neither is HSV. Are they 
*beneficial*? Absolutely. Windows' color picker uses HLS. HLS (and 
particularly HSY) is a more intuitive color space in some opinions. 
Certainly Luma is a much truer concept than Value as far as "brightness" 
of a color, especially when you need to make it lighter or darker. I 
would argue that is more than 'just cool to have'.

The problem with QColor::light/dark is that they are not very uniform in 
behavior (certainly they do not give values that are perceptually 
consistent) and tend to 'get stuck' in certain instances. That is why I 
wrote my own based on HLS color space. They would be better written in 
HSY color space probably, but making that change is trivial since HLS 
and HSY are conceptually identical.

>> there is a blend, 
> 
> right, blending is not a property of color, it's an action (aka. function) one 
> issues on drawable surfaces. And as such has no place in color classes, but 
> in surface (aka. image) manipulation library.

No, it is a function one uses to generate /new colors/ from existing 
colors, like lighten and darken, and has just as much right to belong to 
a color class as QColor::light/dark. Are we on the same page now? :-)

That said, if QColor supported HLS and HSY, I would probably prefer 
making them static members of something like KDEFX, but the question is 
not /where/ to put them, but whether KDE should provide them at all. 
Right now, there are various haphazard implementations (like the ones in 
Plastik, bluecurve-style, and the one that is probably going to be in 
KDevelop 3.4[1]... and those are just the ones I know about). I am 
trying to get a standardized one instead.

([1] see http://bugs.kde.org/show_bug.cgi?id=138730, in particular the 
patch where I had to drop in a blend because none currently exists.)

>> And I know I already mentioned both 
>> 16-bit color and HDR color. Although, if you read the QColor doc
>> closely, you will see it is already 16-bit, it just provides no
>> accessors for the data.
> 
> You realize I work on it, right? :) It's not that I don't appreciate a run 
> down of how our code works, but you'll just need to trust me when I say that 
> it's actually a little more to implement 16bpc support :)

No. :-) But I imagine your definition of '16 bit support' differs from 
mine, especially since you seem to be thinking of HDR and I am thinking 
of '16 bit' in more the meaning of '8-bit vs 16-bit PCM (wave audio)', 
i.e. adding an LSB. Anyway, since I personally care about HDR (by my 
definition which would be 'use a qreal with no upper bound to store the 
color, such that 1.0 = 255 (8-bit) and values > 1.0 are allowed') and 
not 16-bit i.e. 8-bit plus an LSB, I think we can drop this part of the 
conversation. :-)

(But I am curious now which standard Krita supports. In particular, does 
it support floating-point with at least 32-bit IEEE FP precision?)

>> I submitted a pair of "bugs" for QColor HLS and HSY spaces, and for HDR
>> support. But you haven't convinced me that putting the revised blend in
>> QColor is a good idea.
> 
> Probably because I never wanted to and was never doing that. We won't add 
> blend method to color because that's not where it should be. Blending pixels 
> is an absolutely trivial operation that needs no function,

(See above)

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

...And I still want to generate blended colors to use to create 
drawables. ;-)

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