Initial project for GSoC

[Boudewijn Rempt]

On Tuesday 15 May 2007, Emanuele Tamponi wrote:

>
> I'll try to implement the Van Laerohen model: it's a 3-layer canvas
                           van Laerhoven :-)
> structure that updates every dt seconds.
> Every update will apply the changes to the layers, and render the canvas
> contents to the screen.
>
> This can be achieved with Overlays (right?).

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 :-)

> 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.

> The paintop thingie is a bit more challenging.
> The paintop has to be able to get the input from tablet, read the status
> of the canvas, and communicate
> the result of his computation to the canvas (with "canvas" I'm referring
> to the van laerohen's model).

Yes, the paintop can do all that.

> 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.

> 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.

> 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 :-). 

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070516/eb7a7af7/attachment.pgp