'Problems with "embedded" transparency masks onto adj. layers'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kde-kimageshop
Subject: Problems with "embedded" transparency masks onto adj. layers
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2009-09-04 20:17:37
Message-ID: ae32c1ef0909041317g43fa4a1em4b2780ae9f2860db () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

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

[Attachment #5 (text/html)]

Hi, All! I encountered some troubles with selections and &quot;embeded&quot; \
transparency masks for adjustment layers and masks. First of all, i have \
good news - i&#39;ve almost managed to apply usual selection to adj. layers (the \
problem i was reported in bug 205060). And not good news. I can&#39;t \
manage to work freehand painting on the adj. layer&#39;s mask. There are two \
problems preventing me from that: 1) We use selection&#39;s paint device in a \
quite strange way. When we paint with a brush onto selection&#39;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&#39;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&#39;t have it&#39;s own alpha channel. This means \
that during freehand painting you can&#39;t use transparency of your brush, e.g. \
you simply CAN&#39;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&#39;s way. (At least &quot;most popular \
editor&quot;&#39;s way =) ). There are two solutions for that. 1) Most \
obvious way. Just use grayscale8 colorspace for KisSelection&#39;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&#39;s transparency \
pixels (that is not so good in general). The calls are done \
like: selection()-&gt;pixel()-&gt;alpha() ALL THIS CALLS will have to be \
changed to: selection()-&gt;pixel()-&gt;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&#39;s paintDevice in \
alpha8() colorspace. BUT all the painting and bitBlt&#39;ing into this device \
will be done through a special type of a grayscale colorspace, let&#39;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 -&gt; [/dev/null] Alpha -&gt; alpha Our TCS: TCS \
alpha8() Gray -&gt; alpha Alpha -&gt; [used by compositeOp&#39;s] The \
question is: which way to choose? -- Dmitry Kazakov

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop

[prev in list] [next in list] [prev in thread] [next in thread] 