Problems with "embedded" transparency masks onto adj. layers

[Dmitry Kazakov]

Hi, All!

I encountered some troubles with selections and "embeded" transparency
masks for adjustment layers and masks.

First of all, i have good news - i've almost managed to apply usual
selection to adj. layers (the problem i was reported in bug 205060).


And not good news. I can't manage to work freehand painting on the
adj. layer's mask. There are two problems preventing me from that:

1) We use selection's paint device in a quite strange way. When we
paint with a brush onto selection's paint device we just COPY ALPHA
CHANNEL of the brush into selection. I believe this is wrong.

Most of the editors work in the following way:
* rgb component of the brush means the desired transparency level
under your brush
* alpha channel of the brush controls how the brush is painted onto
the selection

Krita uses quite strange system:
* rgb component means NOTHING
* alpha channel of the brush means desired transparency level. This is
very bad, because pixels of the brush with alpha equal to 0 (where the
brush shouldn't have painted anything) WILL set transparency of the
area below brush to 0, instead of just leaving these pixels alone.

More than that, ignoring rgb values of the brush eliminate maybe the
most needed usecase of the masks: gradient masks.


2) [This is a consequence of the 1)]
KisSelection uses alpha8() colorspace and doesn't have it's own alpha
channel. This means that during freehand painting you can't use
transparency of your brush, e.g. you simply CAN'T paint with a circle
brush as you get rectangles instead of circles onto your selection
canvas.

That is why i propose to change this system to confirm usual editor's
way. (At least "most popular editor"'s way =) ).

There are two solutions for that.

1) Most obvious way. Just use grayscale8 colorspace for KisSelection's
paintDevice. The second problem will be solved in a natural way. But
this system has a huge drawback. Much code of Krita uses direct access
to selection's transparency pixels (that is not so good in general).
The calls are done like:
selection()->pixel()->alpha()
ALL THIS CALLS will have to be changed to:
selection()->pixel()->gray()
That is possible, but quite difficult.

2) The second way is not so obvious and needs some help from
Cyrille. This solution leaves KisSelection's paintDevice in alpha8()
colorspace. BUT all the painting and bitBlt'ing into this device will
be done through a special type of a grayscale colorspace, let's call
it transparencyColorspace(TCS). This TCS will have two channels: gray
and alpha. Gray-channel accumulates rgb-values of the brush and alpha
channel controls the shape of the brush. The only difference of TCS
from usual grayscale CS is the way it is converted into alpha8() CS.

Usual grayscale CS:
GCS        alpha8()
Gray  -> [/dev/null]
Alpha -> alpha

Our TCS:
TCS        alpha8()
Gray  -> alpha
Alpha -> [used by compositeOp's]

The question is: which way to choose?

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090905/cc107d24/attachment.htm