Selections on the Adjustment layers

[Sven Langkamp]

On Wed, Sep 2, 2009 at 10:14 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:

>  - Having a separated mask explicitely shows that you can change the
>> transparency and you're sure your tools will perform the same way.
>> Another advantage is that you can drag&drop/copy the mask to another
>> layer easily. When the mask is deleted, the filter layer would be
>> applied on the whole image.
>>
>
> Yes, explicit mask is better, BUT see above and below
>
>
>> - But we can also see things the others way around: Paint layers and
>> Shape layers have built-in transparency too. So maybe it's is more
>> logical to put a built-in transparency mask in other layer types.
>>
>
> I can't remember any "built-in transparency" on paint layers. Do you mean
> 1-100%?
>

The alpha channel is different than a mask. It wouldn't make sense if brush
would have to draw on layer an mask at same time to get a half transparent
color.

 The problem with filter layers is that selections are used as data AND
>> as a filter for other tools. For example:
>>
>
> Yes, double use of selections is not that good.
>

There isn't much difference between a mask and a selection technically.
There are some UI problems though.


>
>
>> There is 4 ways to display a mask:
>>
>
>
>> - as a colored overlay.
>>
>
> Sven said we had that one day, but now it simply doesn't work.
>

Well it works somehow for selection, you can set m_mode(Ants) to
m_mode(Mask) in KisSelectionDecoration.
The big disadvatage outside of the other projections and needs a QImage with
the same size as the image, which is of course no solution for really big
images.


>  Again, here is the behavior of a well-known graphic editor ;P :
>>
>
> Well, that is the problem! "A well-known graphic editor" doesn't have any
> masks other than Transparency masks! (don't speak about selections)
>
> In Krita we have special masks like filter-masks that can't have a child.
> This means they can't have any transp. mask as a child. That's why they
> workaround it with a selection. Adj. layers needn't these selections really,
> but they use to be uniform with masks.
>
>
>
 - Masks are shown on the same line than their parent layer, so it
>> doesn't take more space in the layer docker.
>>
>
> That's a good solution too, but krita's paradigm says that a layer can have
> infinite number of masks. Even if all of them are Transp. masks. I don't
> know how to resolve this.
>
>

There a big differences between Krita and the "well-known graphic editor". I
have to admit that had to look through a few tutorials and wasn't aware how
they solved it.

In Krita you can have masks and layers in the layer stack. While in
Gimp/Photoshop you have the mask directly on the layer.
This design means for Krita is you can apply an infinite number of
transparency or filter layers to a layer.

As far as I can see does Photoshop solve this completely different. They
only have adjustment layers, but these can be applied to layer so that they
work just like filter masks.
Something that I especially like is that you don't need a seperate mask menu
to move masks.

I have to admit that doing it that way looks cleaner, but I don't see any
way to go there from the current system in Krita. I would be tempted to give
such a system a try, if it wouldn't mean such a big rewrite and break.


> Now to resume my thinking :
>> - All masks must behave the same way, even if built-in a special layer
>> type.
>> - The current filter layer built-in mask is almost unusable :/.
>>
> I'm working on this.
>

Just curious. How are you going to solve that?


>  - Selections should not be allowed to paint/erase pixel directly.
>> - Mask data and display of that data should be independant.
>>
> - The user should be able to switch easily between display mode
>> (selection/transparency/...).
>>
> Agree. Sven knows where to fix it in overlay subsys. (right, Sven? ;) )
>
I didn't look into that recently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090903/6fe9dce6/attachment.htm