Initial project for GSoC

[Emanuele Tamponi]

Boudewijn Rempt wrote:
> Depends on what there is on tvl's layers. From his dissertation I get the idea 
> that the layers are:
>
> fluid layer
> surface layer
> capilliary layer
>
> This is quite close to what we had in the watercolors color model. The 
> difference is that pigment (that is, color data) is present in all levels and 
> combined to provide the final output. Color filters down from fluid to 
> surface to capillary layer.
>
> The idea of overlays was a bit different, as based on Tunde Cockshott's 
> dissertatoin:
>
> pigment layer
> 	fluid overlay
> 	surface overlay
> 	capillary overlay
>
> Color remains in the pigment layer but can be moved & mixed due to the 
> properties of the other overlays. This has the disadvantage that we no longer 
> stack pigment in various states, but only have one pigment state per pixel -- 
> namely the value of wetness (fluid), surface height (surface) and speed of 
> evaporation (capillary).
>
> The TVL model looks like it should, like the watercolor colorspace, be 
> implemented as a different color model with values for all three layers for 
> every pixel. Whether that is good or bad, acceptable or not depends a bit. I 
> think that Bart should guide you in this, since he's your mentor. It does make 
> it possible to achieve dry paint that won't smear just because you're 
> painting over it with a wet brush, which is impossible with the overlay 
> model. Krita is flexible enough to allow both models to coexist at the same 
> time, fortunately :-)
>   
Perhaps I didn't understand correctly, I'm writing what I've understood:
an "overlay" should just "affect" the underlying layer, that holds the 
"real" color data.
Using Cockshott model, this is easily done because it's exactly like 
that: a "real pigment
layer" and 3 overlays that alter it using their methods.

Instead, tvl model "splits" the color data into three different layers, 
so we have not the
separation between "pigment layer" and "effects overlays".

Did I get it?

A possible solution - that "could" make my idea colorspace independent - 
is implementing
the tvl model as an overlay, that updates an underlying layer, that 
holds the "final data", using
its own colorspace.
>> This implementation is what I called "Physics filter for drying and
>> running paint".
>>     
>
> Btw, I got a hint from a Corel Painter engineer at LGM2: he suggested to solve 
> the undo system problem by just not putting the filter action on the undo 
> stack. Pressing undo would then go back to the last brush stroke. I'm not 
> sure how that would work since then at every brush stroke we'd have to save 
> the old state of the entire layer. But we'd have to do that, too, if we have 
> time-based undo.
>   
I like the engineer's idea too :-) .
>> The model assures that the paintop code will not interfere with the
>> overlay behavior since it's just about
>> "setting" the initial conditions to the canvas.
>>     
>
> I don't get that.
>   
I just mean that the brush implementation is separated from the canvas 
implementation,
they only contact in the "transfer" of data (pigment, water), not in the 
physics processes of each
other.
>> The color mixer is just a "painterly tool". Do we want to be able to use
>> it only with the painterly paintop,
>> or we want a less "painterly" behavior? In my opinion, the better thing
>> is giving to the user an interface exactly like
>> the "palette" of an artist. So the color mixer would be strictly related
>> to the paintop, and will use something
>> like the 3-layer structure of the overlay.
>>     
>
> Look at the corel painter color mixer -- download or get the trial version of 
> Corel Painter. An important thing is to make it possible to mix paint and 
> load the brush with the complex mix under the brush's footprint without 
> needing separate mixing tools and an eyedropper inside the paintmixer.
>   
I'm downloading :-)
>> But, well, the color mixer needs to be reviewed, I'm not too convinced
>> about it.
>>     
>
> It's a really important part of your gsoc project :-). 
>   
And then we need to review it :-) .

Thank you,
Emanuele