Color Spaces - RGB, CMYK, YUV (fwd)

[Casper Boemann]

On Sunday 05 June 2005 19:09, Boudewijn Rempt wrote:
> 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.
why? The wetCS provides a chooser, and stores the color natively in KisColor. 
For normal painting that's all you need.
When converting to a different colorspace, you no longer need the wet extra 
info.

> The default 
> interchange functions that are now toQColor should, maybe, be converted to
> use XYZ. If that is something lcms supports really well.
well thats what I said. No RGB (QColor) , and it's even more important if lcms 
doesn't support the colorspace in question.

> 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.
Well the ui elements should ask the colorspace what should be provided, but 
otherwise yes.

> > 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.
make that paintdevice, but yes :-)

-- 
best regards / venlig hilsen
Casper Boemann