Color Spaces - RGB, CMYK, YUV

[Bart Coppens]

On Saturday 04 June 2005 15:06, Grzegorz Borowiak wrote:
> On Sat, 4 Jun 2005, Bart Coppens wrote:
> > The lcms stuff also takes care about color profiles, but I don't think
> > there are icc profiles for YUV.
>
> Sorry for lame question, but what are lcms and icc?
lcms is the color management library we use: http://www.littlecms.com/
ICC is the "international color consortium" and defines a standard for color 
profiles: http://www.color.org/

> Well, it looks heavy. But all I need for now is a read-only access. When I
> write something, I'll apply for SVN.
Well, there is always anonymous svn, that's public read-only for everyone. A 
tutorial about svn (I think including anonymous use) is at
http://developer.kde.org/documentation/tutorials/subversion/

> So there's a need to universalize color chooser; I'll try.
Great :-)

> What is 'profile'?
Well, basically, if you display the same picture on 2 different monitors, the 
picture might look different: it might look darker, a bit more blueish, etc. 
Or if you print a picture on different printers, the difference might be even 
bigger. A profile is something that describes how a device will display 
certain colors, so that, when you know how your monitor displays colors, you 
can make the picture look the same on all monitors.

> I would model KisColor after KisPixel, giving it a vector of channels for
> arbitrary use, alpha channel and an enum which would denote the
> colorspace. (alpha channel would be useful in some cases)
Yes, that's exactly what Boudewijn says in his mail :-)

> For each colorspace we need:
>
> * UI for color chooser
Not necesarrily, but it would be handy. The standard color chooser could still 
be used for colorspaces without an UI (converting from RGB), so that we would 
not burden authors of new colorspaces to make an UI as well.

> * names of channels
We already have that :-) See KisStrategyColorSpace's
virtual KisCompositeOpList userVisiblecompositeOps() const
function

> * conversion function from and to RGB (mandatory) and all other
> colorspaces (recommended); if there's no conversion function from X to Y,
> Krita should convert X->RGB and then RGB->Y.
Yes, that is actually what we do now already. The RGB conversion is done by 
the toQColor functions, and we already use them for such things.

> I also wonder of reimplementing KisPixel. Instead of having fields
> m_channels, m_alpha and m_colorStrategy, it should contain a KisColor
> field, or be derived from KisColor, or both should be derived from common
> base.
>
> Such refactoring can be done without changing public section of KisPixel,
> so rest of Krita will remain untouched by this.
Why not just extend KisColor from KisPixel then? :-)