Hi, All!<br><br>I encountered some troubles with selections and "embeded" transparency<br>masks for adjustment layers and masks.<br><br>First of all, i have good news - i've almost managed to apply usual<br>selection to adj. layers (the problem i was reported in bug 205060).<br>
<br><br>And not good news. I can't manage to work freehand painting on the<br>adj. layer's mask. There are two problems preventing me from that:<br><br>1) We use selection's paint device in a quite strange way. When we<br>
paint with a brush onto selection's paint device we just COPY ALPHA<br>CHANNEL of the brush into selection. I believe this is wrong.<br><br>Most of the editors work in the following way:<br>* rgb component of the brush means the desired transparency level<br>
under your brush<br>* alpha channel of the brush controls how the brush is painted onto<br>the selection<br><br>Krita uses quite strange system:<br>* rgb component means NOTHING<br>* alpha channel of the brush means desired transparency level. This is<br>
very bad, because pixels of the brush with alpha equal to 0 (where the<br>brush shouldn't have painted anything) WILL set transparency of the<br>area below brush to 0, instead of just leaving these pixels alone.<br><br>
More than that, ignoring rgb values of the brush eliminate maybe the<br>most needed usecase of the masks: gradient masks.<br><br><br>2) [This is a consequence of the 1)]<br>KisSelection uses alpha8() colorspace and doesn't have it's own alpha<br>
channel. This means that during freehand painting you can't use<br>transparency of your brush, e.g. you simply CAN'T paint with a circle<br>brush as you get rectangles instead of circles onto your selection<br>canvas.<br>
<br>That is why i propose to change this system to confirm usual editor's<br>way. (At least "most popular editor"'s way =) ).<br><br>There are two solutions for that.<br><br>1) Most obvious way. Just use grayscale8 colorspace for KisSelection's<br>
paintDevice. The second problem will be solved in a natural way. But<br>this system has a huge drawback. Much code of Krita uses direct access<br>to selection's transparency pixels (that is not so good in general).<br>
The calls are done like:<br>selection()->pixel()->alpha()<br>ALL THIS CALLS will have to be changed to:<br>selection()->pixel()->gray()<br>That is possible, but quite difficult.<br><br>2) The second way is not so obvious and needs some help from<br>
Cyrille. This solution leaves KisSelection's paintDevice in alpha8()<br>colorspace. BUT all the painting and bitBlt'ing into this device will<br>be done through a special type of a grayscale colorspace, let's call<br>
it transparencyColorspace(TCS). This TCS will have two channels: gray<br>and alpha. Gray-channel accumulates rgb-values of the brush and alpha<br>channel controls the shape of the brush. The only difference of TCS<br>from usual grayscale CS is the way it is converted into alpha8() CS.<br>
<br>Usual grayscale CS:<br>GCS alpha8()<br>Gray -> [/dev/null]<br>Alpha -> alpha<br><br>Our TCS:<br>TCS alpha8()<br>Gray -> alpha<br>Alpha -> [used by compositeOp's]<br><br>The question is: which way to choose?<br clear="all">
<br>-- <br>Dmitry Kazakov<br>