GNOME Bugzilla – Bug 51112
Support layer masks on layer groups
Last modified: 2018-02-05 17:13:12 UTC
I just tried to convince the graphics people of the Gimp and it turned out, that they could not reuse their files created in photoshop because of some features they use. one pf the most important is the masking-groups. our graphics staff makes extensive use of this, because it is much more flexible than single masking layers. is there a chance, that the psd-import will correctly handle this feature in near future? tnx
Could you describe exactly what you mean by "masking groups"? Many of the Gimp developers do not have access to Photoshop, so it is not easy to guess if this is a feature that is missing from the Gimp or if it is something that is already supported by the Gimp but not imported correctly from PSD files by the PSD plug-in.
I'll try... With masking-groups you can define one layer as a mask for a group of "indented" layers. only the part of the "indented" layers, that can be viewed through the masking layer is visible. (sort of a passepartout-effect). In GIMP those groups are simply ignored, so all the layers are treated equally as ordinary layers. In an article in PC-Professional (german edition) it says (i tried to translate it to english): Gimp also opens Layered Photoshop-Files in PSD-Format. Not supported Photoshop-Features like masking-groups are being ignored. http://www.zdnet.com/zdnn/stories/news/0,4586,2145339,00.html It seems, that this is a commonly used feature of Photoshop. Our graphics staff told me that they use it extebnsively.
OK, what you would like to have is the "layer trees" or "layer groups" that have been discussed several times on the gimp-developer mailing list. I have changed the title of this bug report accordingly. Layer trees are planned for gimp-2.0. It is possible that a simpler version of layer groups (only for toggling visibility on/off and maybe for moving a group of layers up/down the layer stack) could be implemented for gimp-1.4, but the development of that feature will probably take several months. This could of course be done faster if you can contribute some patches to implement that feature. Once the core of the Gimp supports layer groups, then it should be easy to import them correctly from *.PSD files.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Reassigned to curent CVS because it's a wishlist item.
*** Bug 81334 has been marked as a duplicate of this bug. ***
*** Bug 85577 has been marked as a duplicate of this bug. ***
The "clipping/masking groups" features from Photoshop is a bit different from what I thought at first. It does not do what I thought that the layer groups should do, but it appears to be a very fast and convenient way to apply the same mask to a group of layers. So I have changed the summary of this bug report and I have moved the other features to a separate bug report: see bug #86337. Using Google, I found several tutorials explaining that feature, including some screenshots showing the dotted line between layers and the indentation that shows that the layers belong to a group: * short description of the clipping groups in steps 5, 6 and 7: http://www.webreference.com/graphics/column4/page6.html * another description with a slightly better screenshot can be found in the last step on this page: http://www.spoono.com/tutorials/photoshop/masks/ * a longer description with screenshots showing multiple clipping groups and explaining the advantages of this feature: http://photoshopgurus.info/beginners/masks-clipgroups4.shtml The last page has the best description, but the other ones may be easier to understand for those who have never used Photoshop. So if I understood these pages correctly, here is how this is supposed to work: * A layer can be used as a clipping mask for the layers above it. I would have done it the other way round, but apparently the Photoshop designers think that it make sense to have the clipping mask below the masked layers. * By holding Alt and clicking on the thin line between two layers in the Layers dialog, you define a clipping group: - The mouse pointer changes to two overlapping circles when you are over the line between the two layers. This shows that a clipping group can be defined there. - Once you click, the top layer is indented to show that it is part of the group and that it is masked by the layer (clipping mask) at the bottom of the group. - The line between the two layers is replaced by a dotted line. * It is possible to add more layers to the group, as long as they are stacked on top of each other consecutively in the layer stack. All of them will be masked by the same clipping layer at the bottom. They will all be indented in the stack and separated by dotted lines, so it is easy to see what layers are part of the group. * The blend mode for the clipping mask (bottom layer) defines the blend mode for the whole group (although each layer can have its own blend mode that defines how it is combined into the group).
Since several bugs reports describe different but similar features related to "groups of layers", here is a list for quick reference: - "linked" layers: bug #51112, bug #86277, bug #86337. - "active" layers: bug #79025, bug #98262 (dup).
*** Bug 101971 has been marked as a duplicate of this bug. ***
The first (and trivial) step to acheive this would be to add a "mask" layer mode which would work just like "erase" except it would take the value to mask with from the color's value instead of the alpha channel.
Yuck! Well, yes, that could work for some very limited cases (masking all layers below the current one), but this would be counter-intuitive from a user interface point of view. Also, even if this would help in some cases, it would still not be possible to define a clipping group (containing only some layers, not all of them) or to change the blend mode of the whole group.
I don't get why this is counter-intuitive. The "group" part of the "clipping-group" feature request is clearly a duplicate of the general layer-grouping/layer-tree request. Once we got this, group clipping comes for free with the clipping layer.
From a user interface point of view, introducing a special blending mode for a layer and using its color value for masking other layers would violate some guidelines about consistency, least surprise, etc. This would only be OK if the layer was displayed in a special way so that it is not seen as just another layer, but as something special that is used as a mask. This is done in Photoshop when you define a clipping mask (see some of the links above and pay attention to how the layers are displayed in the Layers dialog). It would not be appropriate to present this feature as "just another blending mode for a normal layer" because that would confuse the user. Also, as I mentioned above, there is a bit more to the "group" part of the "clipping group": in some ways, the clipping mask is also included in the group. The blending mode of the clipping mask (and only that one) defines the blending mode for the whole group. This would not be possible if the blending mode of the clipping mask must be set to a special value. And this also requires some special code beyond what is needed to implement layer groups (or trees) because AFAIK we did not discuss how to set the blending mode or opacity of the whole group. I think that the main problem in this bug report is to design the user interface correctly; both in the way the information is displayed in the dialog and in the way the user interacts with the application to define or modify the clipping groups and masks. Except for the fact that I still do not understand why the clipping mask is placed below (and not above) the layers that are masked, I like the way Photshop does it and I think that we should design an interface that is as easy to use and understand as Photoshop's.
As we are aiming for layer groups in 2.8, let's put this on the 2.8 milestone.
Bug #86337 which this depends on has been moved to 2.10, setting this to 2.10 as well.
Layer groups are there in master, but I just figured that their mask is oh so broken :( Will fix that for 2.8.
@Mitch: Could you summarize what needs to be done before we can close this as FIXED please?
Created attachment 169829 [details] [review] 0001-app-tests-Add-layer-group-mask-tests-for-rendering-and-XCF-files.patch Attaching test cases patch so it doesn't get lost, to be applied when the tests passes.
Changing title so it applies to current GIMP git master.
Not sure if this helps but the patch no longer works in applying. I did fiddle with it, and it segfaults mainly because the group layer masks's pixel_region is not big enough (when the test tries to set the second row to black, it overshoots the allocated buffer).
Created attachment 199109 [details] [review] test cases patch that can be applied to current tree.
Hi, would it be possible to have a status summary for this feature? From reading this thread, it looks like there is work in progress, but there is no details of what is done and what still has to be. Also the test patch does not apply on master anymore. I did not try to fix the tests, because I first want to understand the status.
Clipping masks and layer masks are not the same thing, which probably isn't news to anyone, but just in case: In PhotoShop, masks can be applied to layers and also to groups. Masks on layers is very useful, and the workarounds are not fun and require flattening the group. This is the simplest explanation I could find regarding putting a mask on a group: https://vtldesign.com/brand-development/tutorial-graphic-design/how-to-mask-groups-in-photoshop/2/ In PhotoShop, apparently clipping masks also can be applied to layers and to groups (I never worked much with clipping masks, but they did seem very useful): http://www.photoshopessentials.com/basics/clipping-masks-essentials/ http://www.howtogeek.com/57159/how-to-use-clipping-masks-in-photoshop/ Bug 86337 seems to imply that GIMP already has group masks. Does GIMP already have something that works like a group mask? If yes, where? If not, I'd like to file a bug report, but there are already a whole lot of "group" related bugs, so maybe there already is a bug report requesting layer masks for groups?
Gimp does not have group masks (although I looked at adding them about a week ago, and it does not look difficult.) This bug report also seems to discuss both clipping masks and group masks. To be honest, I'm not totally sure why you would need both clipping groups and group layer masks. Does anyone have a specific usecase that's covered well by one and not by the other? My general impression is that it would be better to only implement one of them because having both is basically duplicate functionality.
(In reply to Mike Henning (drawoc) from comment #26) > Gimp does not have group masks (although I looked at adding them about a > week ago, and it does not look difficult.) > > This bug report also seems to discuss both clipping masks and group masks. > > To be honest, I'm not totally sure why you would need both clipping groups > and group layer masks. Does anyone have a specific usecase that's covered > well by one and not by the other? My general impression is that it would be > better to only implement one of them because having both is basically > duplicate functionality. They really are functionally different, and you can use clipping masks and layer masks together. A group "layer mask" (a mask that is applied to the entire group) would "reside" next to the group icon in the tool box layer stack). Layer and group "clipping masks", at least in PhotoShop, "resides" below rather than next to the layer/group to be clipped. This article explains the difference: https://blog.udemy.com/masking-in-photoshop/ This article has a nice explanation of using each separately and then both together: http://blog.echoenduring.com/2010/08/12/getting-to-know-clipping-masks-and-layer-masks-in-photoshop/
I understand that they are different, and I understand how they are different. My question is: Why is this difference useful?
Personally I mostly used layer-style masks on groups (and found them very useful). So the only answer I can give from experience is that the clipping mask "felt" like a very different kind of functionality. Sorry! for not having a better answer! Maybe ask on the mailing list?
Are the past few comments arguing against the approach that has been proposed in the attached patches?
I don't understand the code in the attached patches. It almost seems like the group mask only is allowed to show all or none of the composite of the layers inside the group. Could whatever approach is currently available perhaps be committed to master for testing to see how it works in practice?
The code in these patches is just tests. The code for masks on groups is already there, it's the same as the code for normal layers. It's just disabled for groups. Removing enhancement state for more attention.
I played with this a few months ago. What I found was that simply reverting commit df9e9e260990f827b40f9be05114897c571749a2 is enough to get basic functionality for masks on layer groups working (on 2.9, it does not seem to crash). The issue is that when you move or add layers within the layer group, the layer group can dynamically change its size and origin. Right now, the masks behave in bizarre ways when this happens. This shouldn't be too difficult to fix, although to be honest I'm not sure what should happen to the masks in this situation. Two options I considered were either dynamically resizing the mask along with the bounds of the group (but this can be destructive when the group shrinks, which might be somewhat surprising), or simply making the bounds of the group's mask the size of the entire image (but this seems inconsistent and doesn't resolve what should happen when the entire group is moved).
The layer mask resizing also does very strange things to undo, and this *is* hard to fix. I came across something in my stashes that is probably related, will check again...
(In reply to Mike Henning (drawoc) from comment #28) > I understand that they are different, and I understand how they are > different. My question is: Why is this difference useful? A normal mask, either applied to layer or a group of layers is just a greyscale image, where the amount of greys or blacks determine how much of the layer being masked is shown, For example if there is a layer mask filled with 50% black (grey) then the layer or group to which it is applied will have 50% opacity, if it is filled with 100% black then it is completely transparent. Now talking about clipping mask, clipping masks behave in a different way, when a layer(layer 1) is clipped to a layer below it(layer 2) , the contents of the layer (layer 1) that is being clipped is restricted to the opaque parts of the layer below it (layer 2). if the layer1 has lass content and doesn't encompass the layer 2 then layer 2 is also visible in the areas that layer 1 is transparent The layer 2 can be anything it can be a text object, vector object, or any other normal layer. In the article linked by Elle Stone in comment 27 you can see that the word grass is a text object and the grass texture is being clipped inside it, you can change or edit the text object independently, this kind of independent layer editing is not possible in masks, as they need to be just grey scale image. Both are different and are quiet useful in various scenarios. Having both in gimp would be useful, +1 for these two features
(In reply to Raghavendra Kamath from comment #35) > Now talking about clipping mask ... This can be done in 2.9 by changing the layer's composite mode.
Fixed in master (at last :) commit 02a20c6c73c8a718cc03c60f1ca9f2ad5517a348 Author: Ell <ell_se@yahoo.com> Date: Mon Feb 5 10:59:28 2018 -0500 app: add gimp_item_{start,end}_move() Add gimp_item_{start,end}_move(), and corresponding GimpItem::{start,end}_move() virtual functions, which should be called before/after "moving" the item (i.e., translating, scaling, resizing, flipping, rotating, or transforming the item). Moves performed between the outermost pair of start/end calls are treated atomically. What exactly does "treated atomically" entail depends on the subclasses -- GimpItem doesn't provide a default implementation for these functions, so the current commit doesn't change any behavior. The next commit, which adds layer-mask support for group layers, uses the functions to avoid cropping the mask too early while a child is moving. GimpItem calls {start,end}_move() in the various "move" functions (gimp_item_{translate,scale,...}(), before performing the actual operation. Additionally we call the functions in the gimp_image_item_list_foo() functions, for each participating item, so that the items are moved as a unit. We call the functions in the various gimp_image_remove_foo() functions, since removing an item may affect the size of its ancestors, and is therefore akin to moving. We also call the functions in GimpEditSelectionTool, so that the move tool moves items atomically while dragging. app/core/gimpimage-item-list.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------- app/core/gimpimage.c | 41 +++++++++++++++++++++++++++++------------ app/core/gimpitem.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------- app/core/gimpitem.h | 9 +++++++++ app/tools/gimpeditselectiontool.c | 9 +++++++++ 5 files changed, 191 insertions(+), 39 deletions(-) commit 36dec4e6b077851a3ced62e18149d68e4081c060 Author: Ell <ell_se@yahoo.com> Date: Mon Feb 5 11:19:18 2018 -0500 Bug 51112 - Support layer masks on layer groups Add layer-mask support for group layers. Group-layer masks work similarly to ordinary-layer masks, with the following considerations: The group's mask size is the same as group's size (i.e., the bounding box of its children) at all times. When the group's size changes, the mask is cropped to the new size -- areas of the mask that fall outside of the new bounds are discarded and their data is lost (sans undo), and newly added areas are filled with black (and hence are transparent by default). The new gimp_group_layer_{suspend,resume}_mask() functions can be used to modify this behavior. Between the outermost pair of suspend/resume calls, the old mask data is remembered, and is used to fill the newly added areas while cropping the mask when the group is resized. We override GimpItem::{start,end}_move() for GimpLayer, to call these functions (suspend() in start_move(), and resume() in end_move()) for each of the layer's ancestors. As a result, while moving a layer, or a set of layers, atomically, such as while dragging with the move tool, or moving linked layers, the ancestors' mask data is not lost, and is only discarded at the end of the operation. This commit also takes care of properly handling undo for group- layer mask crops, properly invalidating the image when the group layer's mask is shown, and enabling the mask actions for group layers (obviously :). app/actions/layers-actions.c | 6 +-- app/core/core-enums.c | 12 ++++-- app/core/core-enums.h | 6 ++- app/core/gimpgrouplayer.c | 274 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- app/core/gimpgrouplayer.h | 26 +++++++++---- app/core/gimpgrouplayerundo.c | 102 ++++++++++++++++++++++++++++++++++++++++++------- app/core/gimpgrouplayerundo.h | 3 ++ app/core/gimpimage-undo-push.c | 48 +++++++++++++++++++---- app/core/gimpimage-undo-push.h | 14 ++++++- app/core/gimplayer.c | 35 +++++++++++++++++ 10 files changed, 477 insertions(+), 49 deletions(-)