Color manipulation functions in kdelibs?

[Matthew Woehlke]

Zack Rusin wrote:
> On Tuesday 12 December 2006 14:56, Matthew Woehlke wrote:
>> What about my other idea; if I wrote KColor as
>> discussed, do you think that Pigment might want to make use of that?
>> Would it be possible/reasonable to do things so that this hypothetical
>> KColor would support additional color spaces in a dynamic manner? Or
>> would it be better to limit KColor to sRGB space (with support for
>> alternate representations of the same, i.e. HLS/HSV)?
> 
> Why would you need KColor? It just creates unnecessary maintenance burden on 
> you . If there's something QColor doesn't do just report it and someone will 
> implement it. 
>
> Everything I've seen you mention is already there,

Eh? Qcolor::dark and QColor::light do not work the way I need them to, 
HDR is not supported, there is no HLS or HSY support at all, and if 
there is a blend, I haven't found it. /Nothing/ I have mentioned so far 
is in QColor.

Besides, I'm still inclined to want the blending functions in kdelibs 
rather than Qt, if for no other reason than to allow new functionality 
to follow KDE releases rather than Qt releases. I would much rather an 
application/decoration/style depend on a particular KDE version than a 
Qt version.

> what I'd like to add, that 
> hasn't been even mentioned so far, is 16bpc support to QColor for hdr 
> imaging, everything else is trivial.

I thought HDR used floating-point? 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.

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.

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