Color Spaces - RGB, CMYK, YUV

[Boudewijn Rempt]

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

You think those questions lame? You aint seen nuthing yet until you go back a 
year or two and see my initial questions :-)

Anyway, lcms, or little cms (http://sourceforge.net/projects/lcms) is a 
library for color management -- that is, it helps you convert colors between 
color spaces, make sure the colors on screen look a little like the printed 
colors -- that's where profiles come in. White may be 255,255,255, but maybe 
that's displayed as a dirty yellow on your monitor, so you need to correct 
for that. Lcms is a really cool project with a really friendly mailing list 
where I learned a lot.

Now if you want to experiment a bit, try setting a display icc profile in 
Krita's settings box, and then open one image twice. Now go to 
image/mode/Image Properties and give each image a different profile. You'll 
see that the color of both images now differs a lot.

Color management isn't really well-used in X11, but on Windows and OS X 
applications can use a system-supplied color manager. 

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

Better go the anonsvn route then. Simple give:

svn co svn://anonsvn.kde.org/home/kde/trunk/koffice

> What is 'profile'?

See above: apart from compensating for display/printer skew, profiles are 
really necessary when converting from and to cmyk.

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

> For each colorspace we need:
>
> * UI for color chooser

In principle yes, although, for instance, the hsv chooser gives rgb values 
back directly. The way that happens it through setting the currently selected 
back and foreground colors in KisView.

> * names of channels

All colorspaces have a list of channels with their names and types. (There is
color and alpha, but also substance and substrate, for the more complex 
colorspaces that model real paint).

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

That's in the color strategy classes already.

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

No, that wouldn't work. You see, we use KisPixel as a high-level view on 
actual image data. Check the kis_iteratorpixeltrait.h file (maybe differently 
spelled...)

> Such refactoring can be done without changing public section of KisPixel,
> so rest of Krita will remain untouched by this.

I don't think it's even necessary. The basic idea of Krita is currently:

A datastore: that stores the bytes that make up an image in as efficient way 
as possible. Note the word "bytes" -- at this level, there's no difference 
between an 8-rgba color model with one byte, one channel, and a color model 
with a float per channel.

Then, the iterators. These iterate over the image pixels, taking steps of just 
as many bytes as make up one pixel.

Now, when you want to view the pixel as composed of channels, instead of 
bytes, you use KisPixel(RO). The default layout of a pixel is always: color 
channels, alpha channel, substance channels, substrate channels.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050604/890f3c71/attachment.pgp