Color Spaces - RGB, CMYK, YUV

[Bart Coppens]

On Saturday 04 June 2005 13:23, Grzegorz Borowiak wrote:
> > The best thing to do would be to keep a current checkout of Krita, copy
> > the either the rgb or grayscale colorspace module to
> > koffice/krita/modules/colorspace_yuv and start implementing the
> > krita/core/color_strategy/kis_strategy_colorspace interface. If you
> > prefer, I can make an empty template for you to start filling in. Such an
> > empty template might be handy in any case.
>
> Yes, please
Boudewijn already commited this to svn :-)

> > Couple of notes:
> >
> > * We often use lcms to convert between colorspaces. I'm not sure whether
> > lcms supports yuv, if not, you need to use your own conversion routines.
> > (Which my be better for this particular case, I don't know).
>
> No problem, it's just a 3x3 matrix/vector multiplication.
The lcms stuff also takes care about color profiles, but I don't think there 
are icc profiles for YUV.

> > If you haven't got svn access I can do the initial commits for you, no
> > problem, and don't hesitate to ask as many questions as needed.
>
> 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

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

> > 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). Then if you request to 
paint on RGB, it internally converts from its own colorspace to the target 
colorspace. That way, you can have specific YUV color choosers, so you 
wouldn't need to convert to RGB (except when displaying the image to screen, 
of course).

> * YUV requires some work at core, and it's really good moment for it.
Yes, it's indeed a good time for that now :-)

Bart Coppens