Selections on the Adjustment layers

Thu Sep 3 17:37:00 CEST 2009

On Thu, Sep 3, 2009 at 11:18 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

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

I think with the way masks currently work in Krita it doesn't get much
clearer:
http://img197.imageshack.us/img197/8666/adjustmentlayer.png

On one hand it's more clear that you have a mask. On the other hand the
placement below the layer makes it harder to see that there is a mask as
it's only indicated by a "+" and you always you always have to colapse the
tree to edit it.

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

We should think about the possiblity to treat pixel and vector
independently.

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

The major problem I have with the current masks is the order in which the
composition done from user point of view.

Example:
http://img406.imageshack.us/img406/5144/adjustmentlayer2.png

With filter mask it starts with the paint layer, jumps to the lowest child
of the layer and goes upwards while compositing (With explicit masks would
even be one level deeper)
What's also weird is that the preview image of the finished layer would be
shown in the first child of the source layer (last filter mask).

With adjustment layer you need additional group layer, but it has the
advantage that the group layer shows the preview. Another advantage is that
the compositing only upwards.

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

One big problem is that if you have a very slow filter in between real-time
updates are no longer possible.

> > - 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
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090903/b0aa749f/attachment.htm 