Colorspaces and medium interactions

[Boudewijn Rempt]

On Thu, 30 Mar 2006, Leonardo Giordani wrote:

> While I'm working on the implementation of Curtis's paper (watercolors), I was 
> wondering what a colorspace is supposed to contain.
> 
> Namely a colorspace is a reference system that let the user identify colors in 
> the spectral space: according to this RGB, CMYK, Lab, etc, are colorspaces. 
> Watercolors (Curtis's, Levien's, Wet and sticky) aren't colorspaces: they 
> contain a colorspace, but also other functions such as drying, edge 
> darkening, etc. Generally speaking they contain "behaviour" functions.
> 
> So what we call colorspace is something more general, a composition of 
> physical behaviour and colorspace.
> 
> RGB, CMYK, Lab and so on are colorspaces of the "flat" medium (so to say), 
> becouse they simply "paint" the medium, they change the color of the medium 
> itself.
> 
> Wet and wet&sticky are "watercolor" mediums and their have only one 
> colorspace. They interact with the medium in a complex way, for example 
> wetting it, releasing pigment according to its height, etc.
> 
> So my proposal is to re-structure the current "colorspace" directory in order 
> to show this difference and to introduce methods that implements the 
> interaction with the medium.
> 
> This way RGB and friends could simply inherit the standard interaction methods 
> (thus not changing), while watercolors and other fancy things will redefine 
> them. The users could select the kind of paper he prefers (by weight, shine, 
> pattern, etc.) and let the color interact or not with it.
> 
> What do you think about this?

The "standard" interaction methods are implemented in the plugins/tools and
plugins/paintops (especially the latter) location. The reason for putting
the wet paintop, physics filter and so on in one place was for easy experimentation.
I think that still holds. the physics filter and the texture painter in 
particular do belong to the colorspace itself. The paintop and palette are
debatable. 

I think we should keep it this way for the moment, until we really know how
to partition functionality. For instance, I'm currently considering putting
the functionality for simulating canvas (height, slipperyness, absorbsiveness
(if that is a word) into a more generic approach where for every value,
we've got an 8-byte mask like a selection. Maybe I will be doing the same
for wetness. But that's not decided. For now, I think it would be best to
keep all functionality related to watercolors in the relevant colorspace. When
everything is working, we can decide how to refactor it.

And maybe that will mean a subdivision into two different types of 
colorspaces: but maybe we'll be able to abstract common things like paper
and make them generally useful. For now, during work on 1.6, I would be wary
of these things because they will be hard to port to 2.0

Boudewijn