BR = Boudewijn Rempt
ET = Emanuele Tamponi
BC = Bart Coppens
AP = Adrian Page
CB = Cyrille Berger

agenda

layer mask organisation
filter preview
tile backend
natural painting
action recording

natural painting

ET has discovered problems during implementation, he already uses wetness, but it's probably not calculated the right way. They degenerates too fast, wetness goes to the maximum, when drawing. So the range is too small. The problem might because of too much overlays (7 by layer, that mean a total of 14). Solutions:

BR propose to use a separate overlay class with all overlays in one place.
BC proposes to create one colorspace with all overlay.

But BR wants to be able to copy one overlay from on an other. But as the range wasn't enought it's probably required to use float instead of bytes.

Visualization

Visualization of wetness:

animation, recomposite all the stack !
make it only possible for the top layer and only in opengl mode! Using shaders. The infrastructure is in place, BR makes sweet eyes to AP :)

The second big problem, difference between color that can be changed, and color that can not be changed (dried color). Baxter has two layers, wetdream (or the based paper) proposes that when you start painting on a dry layer, then it starts to create a new layer.

Dry paint

Different types of materials:

watercolor, can becomes wet again
oilpaint, it never gets wet, but you can composite it
ink, ink dries with a certain color, when you draw with a different color it has the same effect than watercolor, but it's never wet again
gouache, it doesn't dry

Dry paint is paint that nobody can't paint anymore. BR proposed the group layer to store total wetness and the dry paint, but he decided that it's not a good idea. Second idea is to put the dry paint on a separate paint layer inside the current layer.

BC says that, if on a group layer you have a wet layer (layer 1), then a normal layer (layer 2) then a wet layer (layer 3), if the dry paint is moved in the group layer, the composition would be wrong if dry paint "by-pass" "layer 2".

ET proposed to move the overlay from the paintdevice to the layer, but BR wanted to extend the iterator to support overlay like selectness, but it's a lot of work, and it wouldn't be faster. But BR thinks that ET is right and that we can move it back.

Three paint devices in a layer : completely dry, water projection. ET proposed to have more layer, a new wet layer would be created when a layer becomes dry. In fact it's based on a pixel, when a pixel becomes dry, it is moved to a bottom layer, and on the wet layer the color is erased. But if on the dry layer there is allready a dry paint, then creates a new dry layer.

Dry layers:

three layers in the paint layer
wet + project, and more dry layers

We have a choice, when using a normal paint color:

changing the wet layer
changing the dry layer
leave it to the user

Solution might be to have the layer (dry and wet) appearing in the layerbox, then the user would select which layer (wet or dry) he selects for filtering or "normal" painting.

Mixer

There are two colors, one for mixing and one which is the result. When you mix green with red, you get orange which is what you want, but on the brush you still get something green. With HSV, if you mix red and blue, you obtain cyan and not white.

difference between monodirectional / bidirectional:

for monodirectional the mixer change the foreground color by averaging to follow what's the user expect
for bidirectional

Use CMYK or a spectral wavelength colorspace !

Should the mixer use the same colorspace as the current layer or allways the same colorspace ? Question, which color to select ? BR proposes to choose the color at the hotspot of the brush. One other user option !

filter preview

Docker: out ! Validates what on the wiki.

tile backend

The tiled data manager would be replace by multiple data manager (for instance one for the TIFF, PNG, JPEG those data manager would read directly from the files).

Solution to the swapping, loading from swap file, per thread storage, but there is a problem when thread dies. Multiple thread accessing a single file, a writting thread would "lock" the area on which is writting.

Add an age field to the tiles instead of a list of tiles that can be swapped. That way for each access the tile is time stamped, and then background thread swap the oldest tile.

Pyramids and filter that acts on more than one pixel. Pyramids out of the paint device ? Pyramids only as a zoom cache for final display ?

Filtering on image, creates a pyramid, select a level, and display it. Problems is when to create the pyramid, or allways have the pyramid ?

Pyramids only needs a third of more memory. You just need to add this to the qpainter canvas ? Pyramids at tile level ? It makes it easier to compute the pyramid, and you can have optimization for the composition level.

The big krita lock is going away, time stamps might come in. Display pyramid is going to be at tiled level.or at qimage. BR says that it should be done at qimage level, because it's what we display. Finishing the QImage context class. Should we leave it to linux to swap or not ? Different swap tile backend, one which could swap tiles, and one which could swap QImages. Swapping compressed tiles is problematic because we don't know anymore the size of a tile. But we could store the compressed the tiles with all the same size even if we don't use some bytes. BR is afraid that adding pyramid at the tile level would make it more complicated. BC has to write a mail to list describing exactly what his ideas are.

layer mask organization

The problem is, the current flake design in krita doesn't work. We have a Krita image, we organize our layer stacks (image knows about group layer which knows about sibbling layers and paint layers know about mask effect etc...). The problem is a lot of copy/paste of code. But a layer is a layer but a mask is a mask. The hierarchy of layers couldn't use the shape layer, because that would make krita/image depends on flake (which is apparently is a problem because of QPainter use in KoShape). The interview use the layer hierarchy and not the shape hierarchy, which prevents the use of the layer box in other ko application and raises various problems.

There is a need for a common class for layer, paint, overlay, mask.

option #1, a KisLayer base graph in krita/image, and a mirroring in krita/ui based shape, and the layer box becomes shape based
option #2, no mirroring, krita/image doesn't know the hierarchy
option #3, krita/image use KoShape and have functions which return false

Action recording

Each gui actions would emit a signal with the recorded action information.