GNOME Bugzilla – Bug 131163
moving a layer mask discards information
Last modified: 2004-12-22 21:47:04 UTC
I'm sort of ok with the current way on how to move a layer (its mask moves along) and how a layer moves independently of its layer. However it seems that all the pixels that leave the layer boundaries get reset to white. To illustrate: 1) create a new image 2) create a new layer, preferably smaller than the image canvas 3) fill the whole layer with a gradient so you see how the mask affects the layer 4) create a layer mask. make it 50% grey 5) move the mask to the right a few pixels using the move tool (using shift+cursor keys is very efficient) 6) move it back. If you move the layer back to it's original position, it will not have the original data on the right hand side. It will be reset to white. If you move the layer mask so that all pixels of the mask are outside of the layer at some point, it will get completely 'reset'. I find this behaviour to be broken. The mask should not lose pixel data just by moving it around. In bug #91941, there is a mockup of how to also make the layer move regardless of its mask by incorporating a layer<>mask lock in the UI.
Hi, For me it gets reset to black (transparent), which is perhaps worse. After a few moves I have a fully transparent layer which I can no longer move at all. Cheers, Dave.
Pardon my ignorance. It is indeed black=fully transparent.
Yeah - a graphics artist who can't tell black from white sounds worrying... Dave.
Moving *any* channel discards information. A channel is always a mask for something and can hardly exceed the something. This is consistent behaviour with the image selection and aux channels. We should IMHO not move away from the policy that a mask is always bound to the object is masks and that it cannot be moved independently. When moving, one always moves the pixels is it, not some offset as for layers. Moreover, how should this independent moving behave? When you have moved the mask, say 10 pixels to the right, you expect to be able to paint on the 10 pixels that were moved in from the "outside". We would have to grow the mask drawable infinitely when it's moved repeatedly to be able to moved the stuff back in. I vote for closing this one as NOTABUG sice it currently behaves exactly as the image mask and the semantics of the proposed behaviour are unclear.
I've already faced a similar issue in a drawing app of my own. The problem, conceptually speaking, is that if there are no bounds then the mask is allowed to grow indefinitely: move the mask to the left (say), then draw new shapes on it, then move it again to the left, then draw new shapes, and so on, indefinitely. If you expect to recover what was previously drawn there by moving it to the right, then you have an indefinite-size image, and that's not how real-world programs usually work. The semantics I came with as a solution implied to use offsets when moving the mask, and perform the truncation (resetting the offsets) just before the mask is modified. In this way nothing is lost while moving the mask around, only when painting over it after being moved. NOTABUG is thus perhaps not the best resolution here. WONTFIX is a possibility, and setting the milestone to Future, even better. It's worth noting that such a change may imply changing the XCF format.
Personally I'd prefer having the 1.2 behaviour - the move tool moves the layer with the mask even if the mask is selected. It is a bit awkward to move a mask alone (floating it first), but at least it's not so easy to move the mask accidentaly when I have a mask selected (which I do often by mistake). But that's a very personal opinion. The new way may be better to someone else. I tried getting used to it, but it really annoys me to lose parts of it by mistake (and you have to realise right after the mistake to make use of undo).
Well, it's as easy as accidentially painting on the layer mask instead of on the layer. I think things should behave consistently. The real problem here is IMHO that the layer mask being active is announced only by these small black and white borders in the layers dialog. Perhaps we need a more prominent indicator for this. Any idea?
Change the color of the layer boundary? We'd have to make sure we use a color scheme that works for color-deficient but it should be possible to find such a combination. Finally a chance to put the display filter to use.
I would prefer having the canvas border color change rather than the layer boundary. I have it toggled off most of the time since it's interfering visually with the artwork too much. Another visual aid to make it clear one is working on the mask might be changing the cursor somehow. Perhaps inverting colors or somesuch (might be problematic once we have nice RGBA dropshadow cursors).
Can we close this one as NOTABUG and open a new enhancment request for a more visible "layer mask active" indicator?
Sure. What would be nice would be to have the inactive bit (the mask or layer) be greyed. At least, I think that would look good. Cheers, Dave.
*** This bug has been marked as a duplicate of 132204 ***
Resolving as duplicate of the correct bug. *** This bug has been marked as a duplicate of 91941 ***