Color manipulation functions in kdelibs?

[Matthew Woehlke]

Boudewijn Rempt wrote:
> On Monday 11 December 2006 23:52, Matthew Woehlke wrote:
>> Clarence Dang wrote:
>>> [adding Krita people to CC as I'm sure they have more to say]
>> Good idea, although it occurs to me that Krita will probably want to
>> have its own set of functions, specifically so they can handle things
>> like 16-bit color (and - can I hope? - 32-bit FP color a.k.a. HDR
>> color). But you are right that they might have suggestions.
> 
> Krita already handles HDR pretty well.

Ok, I haven't checked. I *really* want to have a look at Krita one of 
these days :-), but, well, I need a better install on my home computer. 
(right now I am running on a 95% full 2GB drive. Seriously.)

> Krita's underlying color library,
> Pigment, has just been moved into koffice libs, instead of being Krita 
> specific. It's no more than a day work to create a basic new colorspace for 
> Pigment, maybe a little longer if you want all fancy blending modes, a little 
> longer still of there is no icc profile possible for the colorspace you're 
> implementing. All colorspaces except Lab and 8-bit alpha are plugins.

Does Pigment not already support at least an 8-bit version of HLS? Does 
it support true-gray HLS or... well, I'm not sure what to call the other 
one. "True gray HLS" means that any HLS color converted to grayscale 
(using true gray conversion, i.e. the one with weighted RGB 
coefficients) will preserve the 'L' value. The alternative is where S=1, 
L=0.5 always gives a 'pure' color (i.e. the same as HSV with S=V=1).

>> It also occurs to me that we should probably expose things like
>> 'desaturate', 'colorize', etc; i.e. all the things the icon effects do.
>> Although I expect these would mostly be convenience wrappers for
>> particular permutations of blend*/lighten/darken.
> 
> Pigment has got those already.
> 
> If people think that Pigment would be more generally useful then it may be a 
> good idea to put it in kdelibs, or make it a completely separate library.

That's a really interesting question. My first reaction is that this is 
overkill for the needs of e.g. UI and style writers (which is why I 
brought up the question originally), but I bet other applications could 
benefit. Certainly any graphics application could benefit, and probably 
scanner software also.

Does KOffice depend on kdegraphics? If so, it might be a good idea to 
take some of the lower level functionality of Pigment and put it into 
kdelibs, and put the rest in kdegraphics. Otherwise, what do other 
people think about putting Pigment in kdelibs?

-- 
Matthew
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!