Color Spaces - RGB, CMYK, YUV

[Grzegorz Borowiak]

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?

> > Could I get svn access?
> Well, normally you'd need to have done some work already on kde/koffice, but
> I'm sure that if you plan to do things like this, they would give you access
> as well. You can find more about getting svn access here:
> http://developer.kde.org/documentation/misc/applysvnaccount.php

Well, it looks heavy. But all I need for now is a read-only access. When I
write something, I'll apply for SVN.

> > > Now this would be possible with krita, for the most part of it. If you
> > > know how, Krita would be able to display YUV frames, and you would be
> > > able to draw on them. As far as I know, the main problem is that at the
> > > moment, that the paint brush still works only in RGB,
> >
> > What does tie it to RGB?
> The fact that the color chooser and so all operate on RGB I think.

So there's a need to universalize color chooser; I'll try.

> > > KisPaintOp::computeDab(KisAlphaMaskSP mask) (in
> > > core/paintop/kis_paintop.cc) where you'll see that it uses a QColor. Now
> > > you could probably play with this a bit, to work around the curent
> > > limitations. But that's of course for after getting YUV working, I think
> > > :-)
> >
> > Generally I think we could replace QColor with some KisColor class, which
> > would have similar interface but be more universal.
> Yes, I think that's the idea. I think we had a KisColor class at one point,
> but we abandoned it, does anyone now if that is correct (and why)?
>
> Now I think a KisColor class could have something like an 'internal'
> colorspace (with possibly an associated profile).

What is 'profile'?

> Then if you request to paint on RGB, it internally converts from its own
> colorspace to the target colorspace.

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)

For each colorspace we need:

* UI for color chooser

* names of channels

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

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.

-- 
Grzes