Color Spaces - RGB, CMYK, YUV (fwd)

[Boudewijn Rempt]

On Sun, 5 Jun 2005, Casper Boemann wrote:

> KisColor should internally be based on XYZ (or lab), but not RGB. This to
> provide the largest possible gamut.

Er, no. KisColor should store the color natively to the colormodel of the
color selector. Limiting ourselves to xyz or lab will make it very hard to
create color selectors for the wet paint color model. The default interchange
functions that are now toQColor should, maybe, be converted to use XYZ. If
that is something lcms supports really well.

Keep in mind that for rgb and cmyk we should convert using lcms and profiles
if possible at all. That's the only reliable way to make useful color separations,
determine out-of-gamut colors and all the other things.

> The user should have several ways of specifying color. In my mind it should be
> a limited set including hsv and rgb, but in special cases like gray and with
> substance channels we should provide a colorspace specific chooser. I don't
> know if this is needed for YUV, but perhabs we should always provide the user
> with rgb,hsv, plus the specific colorchooser, with the option of disabling
> rgb and hsv if it doesn't make sense (as in gray).

It will be necessary to disable not only color choosers but also other
parts of the user interface based on the color model and other properties of the
active layer. The easiest way to do is to emit a slotLayerChanged(layer) from
KisCanvasSubject that all user interface elements can (and really should)
connect to.

Then, based on the colorspace and other properties of the layer each user inteface
element can decide whether it should enable or disable itself.

> KisPixel should be based on whatever colorspace the associated canvas is.

Make that layer -- but for the rest, yes. There's no reason to change the
design of KisPixel.

Boudewijn