Selections on the Adjustment layers

[Boudewijn Rempt]

On Wednesday 02 September 2009, enki wrote:
> I think both built-in and separated masks makes sense :
> 
> - 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.

I think that makes sense, so I would support removing the built-in selection 
of KisAdjustmentLayer and create it with a transparency mask by default. It 
would make the way krita operates clearer to the user, I think.

> - 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.

Well, that's a different sort of transparency, or rather, two: the alpha 
channel of a layer and the layer's opacity. Although here implementation 
details might peep out into the user interface, which is generally a bad 
thing. So, right now, the opacity of a pixel in a paint layer is determined by 
three things:

* the alpha channel of the pixel (which is set during painting)
* the opacity value of the layer (a layer-wide property)
* the opacity value of the 0 or more transparency masks associated with that 
layer (possibly created from the alpha channel, or from a global or local 
selection).

> The problem with filter layers is that selections are used as data AND
> as a filter for other tools. For example:
> - Let's say that I want to paint inside a selection: I can't create that
> new selection because if I do, it will overwrites the existing mask data.
> - If I erase with a paint tool, it erase the selection, but if I paint,
> the selection isn't extended, because paint tools are bound by the
> selection.

Well, that's a bug: the selection component of a filter layer should not be 
interpreted as a selection when manipulating pixels. The selection is the 
paint device of the layer, it's what we paint on, and a local or global 
selectoin should constraint painting on it, not the selection in the 
adjustment layer.

> - I can't use global selections to manipulate pixels.
> 
> There is 4 ways to display a mask:
> - by the effect it has on its parent.
> - as a selection.
> - as a greyscale image.
> - as a colored overlay.

We should treat our mask visualization issues as a bug, really, and not as a 
feature. I.e, it should be fixed for 2.1.

> In our case, we shows two kind of display at the same time(selection +
> effect). That's very confusing. It's a bit like mixing two different
> charts that use the same data.
> I think the built-in mask in filter layer and filter masks should behave
> exactly like the transparency mask.
> Also, the user should be able to switch from the display mode
> (selection, overlay...) when he need to. But that raise new problems :
> Vector selections are lost if we convert them to another mode (that
> doesn't happen in other editor because they force the user to convert
> vector shape to raster selection). 

I'm not happy with our solution either -- if we make  filter layers paintable 
at all, maybe we should make it an ordinary paint device and indeed rasterize 
any vector selection that's set on the adjustment layer.

> But I think an user that really want
> to keep his selection will save them in a local selection anyway.
> 
> Again, here is the behavior of a well-known graphic editor ;P :
> 
> - Any layers can have a mask and it always works the same way.
> - Adjustement layer are created by default with a child mask.
> - A mask is a channel of the current layer:

I have never been able to understand that part of Gimp or Photoshop -- it 
always seemed to me as if masks in those applications were a kind of 
historical outgrowth of the alpha channel instead of something in their own 
right.

>     *If the mask is set "hidden", its transparency effect is applied on
> the layer(default behavior).
>     *If the mask is set "visible", you see it as a colored overlay.
>     *If the mask is set "visible" but, other channels are hidden, the
> mask is shown as a greyscale image.
>     (not really user-friendly uh ? ^^)

I think the current Krita design is better. Our implementation needs work, but 
then, every time I tried to work on it, something more important was brought 
to my attention so I never had time to finish it.

> - You can paint on masks as if it was a greyscale layer. Black =
> transparent, white = opaque. That make it easier to use paint tools.
> - You can display a selection as an overlay at any moment, paint on it,
> and display it as selection again.
> - Masks are shown on the same line than their parent layer, so it
> doesn't take more space in the layer docker.
> 
> 
> 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 think that's mostly an implementation issue, really.

> - 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/...).


-- 
Boudewijn Rempt | http://www.valdyas.org