Pigment and colorspaces

[Bart Coppens]

On Wednesday 07 February 2007 15:20, Leonardo Giordani wrote:
> Hi, after a long pause due to medical problems I'm about to begin again my
> work on colorspace. I'm sorry that my development goes slowly.
No problem at all :-) Great to hear from you again.

> 1) I am confused by the pigment and colorspaces stuff. What goes exactly in
> pigment and what in colorspaces? Furthermore, there is a "colorspaces"
> folder in koffice/libs/pigment/ too: what is this compared with
> koffice/krita/colorspaces?
The colorspaces in libs/pigment is the folder containing the hardcoded 
colorspaces needed for pigment to work. Rgb8 isn't there, I don't know 
exactly why.
The colorspaces in koffice/plugins/colorspaces/ are the regular ones, that all 
KOffice applications using color management via pigment will probably need. 
This is stuff like CMYK, RGB and Grey.
The colorspaces in krita/colorspaces are the ones that non-Krita apps will 
probably not need. This includes 'artistic' ones, like wet, and the ones that 
are more specific for image applications, like lms_f32. Why we have grey 
there and in koffice/plugins is not entirely clear to me either.

> 2) KoAlphaColorSpace implements many methods such as fromQColor(),
> toQColor(), channelValueText(), etc... (KoAlphaColorSpace.cpp?rev=625077),
> but both KoLabColorSpace and KoRgbU16ColorSpace (in pigment/colorspaces
> too) do not implement them? Why?
I think that's because these are already implemented in the base classes for 
those. The exact details as to how the traits thing work exactly, Cyrille 
will be better to answer.

> 3) What is the "d-pointerification" I can see more or less everywhere in
> SVN?
That just means that in public libraries, we store all private fields of a 
class in a single member. This is to ensure binary compatibility over a 
certain period of time, but it's nothing that you need to worry about if you 
code plugins.

> 4) I remember that I experienced difficulties managing the canvas, i.e.
> the "quint8 *dst" you can find in setPixel() methods, for example in
> kis_lms_f32_colorspace.cc, but in general I didn't understand when and what
> methods are called... For example convertToQImage(). No one of you can
> write something detailed about what is expected from a colorspace and how
> it works? Or perhaps I'm losing myself in a simple thing?
The setPixel for the lms_f32 plugin is internal, you don't have to use or copy 
that. In general, the quint8* are just pointers to the raw data that your 
colorspace will interpret; all Krita functions should in general not know 
about the exact details of your colorspace. So we use a 'generic' pointer 
type, so that we don't risk that anybody will try to use the data in itself. 
Then you can in your colorspace functions interpret that pointer data, and do 
stuff with it.

Bart