bugMyPaint - Bugs: bug #20359, [WISH] Grouping of layers in...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #20359: [WISH] Grouping of layers in MyPaint

Submitted by:  Joshua Tyler <marand>
Submitted on:  Sun 09 Dec 2012 05:50:23 PM UTC  
Severity: 1 - WishPriority: 5 - Normal
Status: FixedPrivacy: Public
Assigned to: Andrew Chadwick <achadwick>Open/Closed: Closed
Release: gitPlanned Release: None
Operating System: 

(Jump to the original submission Jump to the original submission)

Mon 23 Jun 2014 04:20:51 PM UTC, comment #8:

MyPaint's git master has layer groups (proper ones, implmenting the Compositing-1 model) for ages, and the OpenRaster spec has been updated too, so let's close this bug now :)

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sat 18 Jan 2014 03:55:06 PM UTC, comment #7:

I've a branch myself now that does the stacking thing and implements the W3C SVG layers model in part: https://gitorious.org/mypaint/achadwick-mypaint/commits/layer-enhancements-exp . Their spec has moved to http://www.w3.org/TR/compositing-1/ , btw.

Quite a major refactor, unfortunately; though it also adds things like support for SVG layers (or anything else GdkPixbuf can load)

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Fri 04 Jan 2013 10:29:23 PM UTC, comment #6:

This is actually a duplicate of the older bug bug #18317. But since this one has more info I am keeping it open and closing the older one.

Jon Nordby <jonnor>
Project Administrator
Tue 11 Dec 2012 11:16:14 AM UTC, comment #5:

Librarian's layers branch: https://gitorious.org/~zrzz/mypaint/librarian-mypaint/commits/layers

Forum post: http://forum.intilinux.com/mypaint-development-and-suggestions/group-layers/

Mailing list discussion: https://mail.gna.org/public/mypaint-discuss/2012-12/msg00021.html

Not sure how useful it is to mention, but we tend to base a lot of OpenRaster's approach to layer compositing and blending on the W3C specs for SVG (and other things with layers) because they've already done the heavy lifting. There are some scraps of information regarding how isolated layer groups (will) composite on the web in the recent Compositing and Blending, http://www.w3.org/TR/compositing/#isolatedgroups. FYI I'm pondering making compositing operations specifiable in ORA, becuase there are differences between Gimp's approach and MyPaints already. And Krita too, doubtless.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Mon 10 Dec 2012 06:26:56 PM UTC, comment #4:

I submitted about groups to the mailing list. Sorry, didn't know it was on forums. Now it on three places.

Well, from what I gathered playing about month

1) Moving single layer as is, then moving children in finalizer works fine. (in my fork on gitorium there are no groups per se, but layers are linked by name and can have child layers)

I'm actually not sure that moving all layers in dran'n'drop is a good idea: moving one single layer 1500x2500 is shaky already so I can clearly see tiles. Moving ten of them probably would be nightmare.

Maybe add translate_x, translate_y into Layer, use it to render layer and perform actual movement in finalizer of LayerMoveMode?
(Though honestly I didn't figure out yet where layers are actually being rendered and if it possible to translate their rendering without huge work)

2) Changing opacity is simple to implement already(I did it in fork). You need only to modify effective_opacity to multiply opacity it by effective_opacity of parent. (It's probably wise idea to cache multiplier, but that's not the point)

3) I'm not sure about layer group visibility.

Very often I want to disable visibility of the whole group, but leave one layer visible(like Home key, but for group). Personally I think that visibility should be determined as follows:

1) If layer is not visible, do not do not display layer
2) If parent group is not visible, do not display layer
3) Ignore parent group visibility if layer is visible and this setting was done later then parent's visibility.

E.g. we have group G, and inside layers L1, L2, L3.

  • turn off visibility of L1: it became invisible,
  • turn it on: L1 became visible
  • turn off G: L1, L2, L3 became invisible
  • turn visible on L2: it became visible because even though its group invisible, its own visibility setting was set after group visibility and therefore overrides it.

What do you think about this approach?

Libra Rian <zrzz>
Sun 09 Dec 2012 08:16:44 PM UTC, comment #3:

> Thank you for reporting it so concisely and thoroughly! Post-1.1, I think: it's quite a lot of work, just internally since the code currently makes a lot of assumptions about stack layout.

No problem! The way I see it, if I can't take the time to explain what I want well, I can't expect someone else to take the time to do it. I would have requested it long ago, but for some reason I assumed ORA couldn't do it without a change to spec. Only recently saw otherwise I saved to the format in Krita.

> Layer move - what happens if you move the bottom layer of a tree? Presumably the whole stack will have to move with it. Not fun with a tiled memory structure, but at least we have much of the work done.

If you mean moving a layer within canvas, only the layer you move would be affected. To adjust all layers you adjust the group itself, which gets displayed as an adjustable layer. At least, that's how Krita does it, and gimp seems to act similarly, though I only tested it briefly.

For example, if you have a document with the following group structure: group "Foo" with four layers ("sketch" "inks" "flats" "shading"), a background, and a foreground, the layout would be something like this (assuming formatting works in my favour):

  • Foreground
  • Foo
  • * Inks
  • * Shading
  • * Flats
  • * Sketch
  • Background

You could select 'Foo', which is a group layer, and set things like its opacity and visible-ness. If you select 'Foo' and move the layer, then the four child layers will be moved at the same time, all in sync with each other. If, instead, you select "Sketch" and move it, it will move independently of the other layers.

It would be silly in the example I gave, but less so if you had, say, a group called "Dialogue Boxes" for a comic: you could move or change visibility of all boxes at once, but still rearrange them within the comic manually by adjusting the individual layers.

That's assuming I understood the question correctly, of course.

> Dragging in the layers list, adding new layers (inside current, top level), merging...

To continue using Krita as an example, since I'm more familiar with its implementation than Gimp's: Krita always tries to add a new layer within the active group, directly above the currently selected layer. If the selected layer is a group layer, then it adds the new layer to the top of the group's stack.

Dragging generally figures out the appropriate context, though it's not perfect, at least with regard to placing a layer between the end of one group and the beginning of the next. UI buttons exist for moving into and out of groups, though, represented as left and right arrows (← and →).

I just tested the group merging behaviour, and it looks like Krita flattens the group for all group-related merges. Merge a single layer onto a group, and it flattens the group and then makes a single layer from merging that composite with the other layer. Likewise for group-on-group: both are flattened then merged. This surprised me, actually: it's extremely destructive behaviour that is also fairly obtuse.

Gimp won't allow you to merge layer groups into other layers at all. Layers inside a group can be merged together, layers outside can, but never shall a group itself merge.

I personally think Gimp's behaviour is the correct choice here, even if it is less convenient. Maybe Krita-style merging with a warning box of some kind?

Joshua Tyler <marand>
Sun 09 Dec 2012 06:54:35 PM UTC, comment #2:

Thank you for reporting it so concisely and thoroughly! Post-1.1, I think: it's quite a lot of work, just internally since the code currently makes a lot of assumptions about stack layout.

There are also some workflow questions we may just need to experiment with in the code (sometimes that's the easiest way to stumble across questions you haven't thought to ask yet!). Off the top of my head...

  • Layer move - what happens if you move the bottom layer of a tree? Presumably the whole stack will have to move with it. Not fun with a tiled memory structure, but at least we have much of the work done.
  • Layer and stroke pick - is this affected?
  • Dragging in the layers list, adding new layers (inside current, top level), merging...

... there'll be a lot of stuff to play with.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sun 09 Dec 2012 05:51:40 PM UTC, comment #1:

Sorry for the markup failure, the auto-numbering apparently doesn't work with linebreaks between.

Joshua Tyler <marand>
Sun 09 Dec 2012 05:50:23 PM UTC, original submission:

As suggested by achadwick on the forums (post: http://forum.intilinux.com/mypaint-development-and-suggestions/group-layers/msg11826/#msg11826 ), a wish report for layer grouping, with examples of use cases.

I'm not the one that requested layer grouping on the forums, but I would like to see the feature implemented as well, so I decided to make the report and get things started.


  1. Organisation of complex documents. Being able to expand and collapse groups of layers helps simplify navigation of the layers list in a large file with many layers. Collapsing groups you don't need currently can reduce scrolling. Grouping also allows you to rearrange multiple layers in the stack simultaneously, by moving the group to a new place in the stack. Things like reference images can be grouped, reducing visible layer clutter.
  1. Visually, it can be easier to find certain groups and layers within them due to the nested structure. In a scene with three characters, for example, you could make a group for each character, and then have layers for pencils, inks, flats, and shading in each group. Instead of having to check every layer in the list, you can find the appropriate group, and then check inside it for the layer you want.
  1. Grouping is a more flexible, powerful, and obvious concept than layer linking. If you have three layers inside a group, you can still perform layer operations on the individual layers like normal, but if you select the group and perform the interaction, it affects all members of the group, akin to linking. A well-organised document can be easier to make adjustments to because of this. For example, a layer group containing all of a scene's background elements on separate layers. You can move or toggle visibility of the entire background as needed in a single action, but you can still manage each element separately to fix problems like scale or positioning.
  1. Following on #3, grouping allows you to set certain layer traits to an entire group instead of on each layer, giving more control over layer interaction. You can set the opacity and layer blending modes of the group instead of the layers, and it acts on the composite of the grouped layers, rather than each layer separately. For example, two layers with normal blend mode, 100% opacity, inside a group that has has 50% opacity and overlay mode: the layers would combine normally, with the higher layer obscuring parts of the lower, and the resulting composite is then used for the 50% opacity overlay.
  1. Can help reduce layer clutter. Some features of layer grouping can be emulated without grouping through use of layer duplication and merging, but this requires keeping extra copies of layers. This is the sort of thing the software could (should?) handle so the user can focus on doing what he or she wants instead of coercing the software.
  1. Consistency with Krita. Krita currently saves layer grouping information inside ORA files, but this gets obliterated in a Krita<->MyPaint workflow. They're good tools to use together, and it would be nice for MyPaint to not massacre the information, even if it doesn't make use of it. (I believe gimp obliterates the grouping data too, but this isn't about gimp)

Well, that's everything I can think of right now. Thanks for reading.

Joshua Tyler <marand>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by jonnor (Posted a comment)
  • -unavailable- added by zrzz (Posted a comment)
  • -unavailable- added by achadwick (Posted a comment)
  • -unavailable- added by marand (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 23 Jun 2014 04:20:51 PM UTCachadwickStatusIn Progress=>Fixed
    Sat 18 Jan 2014 03:55:06 PM UTCachadwickAssigned toNone=>achadwick
    Tue 11 Dec 2012 11:16:14 AM UTCachadwickStatusConfirmed=>In Progress
    Sun 09 Dec 2012 06:54:35 PM UTCachadwickStatusNone=>Confirmed
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup