Impasto discussion

[JL VT]

On Thu, Jul 8, 2010 at 12:02 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:
> Well, i have a couple of considerations.
>
> Will this "impasto" information be somehow "derived" from real layer data?
> Or it'll be written directly by paintops?
> Why do i ask? If it can be calculated from the layer itself, then it can be
> represented by the mask of the layer (somehow).
>
>
> Actually, i think, "impasto" information is a property of every pixel,
> right?

Yes, it is.

>What is the reason in special layers, then?

None in particular, it's the first method that seemed able to solve
the problem that came to my head.

> In my opinion, this special "property" of every pixel should go to a special
> colorspace with a special channel, named "thickness" or "height".

That sounds much more intuitive to me too.

>There can
> be a problem, because impasto-capable colorspaces should be created for
> every meaningful colorspace, though it can be, i think, solved with some
> templates or whatever.

I don't think that's a problem. I can start development by making an
impasto-enabled RGBA colorspace and see how it goes. This also has the
advantage of not breaking Krita for anyone while I work in the main
branch.

>
> What are the benefits of this:
> + you needn't change paintop system to be capable to paint onto two(!) paint
> devices simultaneously. btw, it will be much more slowly, than writing to an
> additional channel
>
> + you needn't do two separate updates for one change (traversing the layer
> stack with compositing is quite expensive operation). More than that, adding
> "special" layers to the stack will make UI really weird. The user will have
> to answer a few quite non-intuitive questions: "how do Adjustment Layers and
> Masks (e.g. blur mask) will effect to this "special" impasto layer?" Or
> "what will happen if you change the parent of an impasto layer?"

Very convincing so far.
The speed part was my greatest concern. If you tell me this method is
much cheaper than the other, then with just this in mind I'd be
inclined to choose this method.

>
> + and you needn't change the merging system. Yeah, technically, it is
> possible to achieve this with a special Walker, but... i wouldn't do it, not
> for love or money! =)

Yep, very convincing  :P

> drawback:
> - you need to solve the issue with adding impasto for all the colorspaces

Small drawback for the benefits

> So what do i suggest:
> 1) You create a special colorspace (or colorspace template) that can hold
> one more channel for the height.
> 2) You modify, if needed, COMPOSITE_OVER and other operations of this new
> colorspace to make SUM of "thickness" channels.
> 3) Then you need to add ability for paintops to paint on this additional
> channel. I don't think it'll be difficult -- you just need to modify a dab
> of the paintop.
>
> /* by this moment, you will have a well-prepared projection with all the
> impasto information included */
>
> 4) Then you create a special filter, that will modify RGBA pixels of the
> projection according to information in the "height" channel.
> 5) Then you wrap this filter into a mask and hide (or not to hide... that is
> the question...) inside a root layer.
>
> And that is all! =)
>
> Who to contact:
> 1,2 - Cyrille
> 3 - Lukas
> 4,5 - me

What does everyone else think of Dmitry's idea?