[POLL] Assistant layers, masks, list, docker, tree?

[tiar]

There are multiple versions of all of those concepts floating around in the ether. Time to figure out which one should be implemented.

When judging, please keep in mind the following usecases:

• complex paintings with plenty of assistants
• comic pages (every panel has their own assistants)
• maybe animation

Assistant Masks

In my opinion, this is one of the most useful ideas. Similar to Local Selections.

In that idea, assistants are stored in masks that you can attach to all kinds of layers (including group layers). If you attach it to a paint layer, you can only use the assistants on that paint layer. If you attach it to a group layer, you can only use them in that group. There can be multiple assistants on a mask.

Like Local Selections, global assistants (not attached to any layer) will still be possible. Unlike with Local Selections, it will be possible to have multiple Assistant Masks active at the same time.

Possible new feature: separating visibility of the assistant from the activeness.

Since the other most popular option is Assistants Tree, I think maybe there should be a way to introduce this kind of mechanism here too. But I’m a bit worried whether making it possible for Assistant Mask to be attached to other Masks is a good idea… It breaks what users know about Krita (that masks can be attached to layers or groups but not other masks).

IT WILL STILL BE POSSIBLE TO USE ASSISTANTS JUST LIKE YOU USE THEM NOW (not attached to any layer, “global”).

+ Pros +	- Cons -
+ when attached to a specific layer (group),	- takes space in Layers docker
… . assistants will only work on that layer (in that group)
+ separates global assistants from assistants just for
… . a specific thing (like ellipses for car wheels)
+ could potentially be use for animating
… . assistants in the far away future
+ easy access to visibility and other settings for assistants
+ you can name the mask however you want

Assistant Layers

I believe people asking for Assistant Layers either mean “Assistant Masks”, or “Assistants Docker/List”.
If you have an idea about usefulness of actual layers in Layers docker with assistants on them, please do share.

Assistant Docker (list)

List of assistants in a docker or maybe Tool Options (but usually a new docker).

Pros:

• easy access (changing visibility, color, lockedness etc.) to all assistants (especially when in a docker)
• individual layers can be named
• doesn’t take up space in Layers docker

Cons:

• takes space on the workspace (if in a docker)
• difficult to access when working with other tools (if in Tools Options)
• no way to separate assistants for different things, all assistant are global

Assistant Docker (tree)

The same as Assistant Docker List, but in a tree, like layers.

Question is whether the equivalent of Group Layers should be other assistants or just abstract nodes (like Group Layers don’t contain any new pixels, they just group things).

Pros:

• easy access (changing visibility etc.) to all assistants (especially when in a docker)
• individual layers can be named
• doesn’t take up space in Layers docker
• you can change multiple assistants at once easily.

Cons:

• takes space on the workspace (if in a docker)
• difficult to access when working with other tools (if in Tools Options)

POLLS

Please do comment as well! Give your own ideas, comment on the existing ones! The poll is just because I thought it would be fitting here.

Choose just one option:

• Assistant Masks
• Assistant Layers (please explain how it should work in the comments)
• Assistant Docker - List
• Assistant Docker - Tree
• Assistant List in Tool Options
• Assistant Tree in Tool Options

You can choose two options here:

If you think both should be implemented.

• Assistant Masks
• Assistant Layers (please explain how it should work in the comments)
• Assistant Docker - List
• Assistant Docker - Tree
• Assistant List in Tool Options
• Assistant Tree in Tool Options

[LaTor]

For the Assistant Mask, would it be possible to have the assistant on a layer, for example a sketch layer, and then turn it off or on without affecting the sketch layer to ink or color on a different layer? Would the assistants also be limited to panels on a different layer but attached to the sketch layer?

I was curious since multiple assistants can be placed on a single mask, which I am in favor of, but I wasn’t sure if it is possible to limit the multiple assistants on one mask to different panels on a separate layer, mostly for long webcomics.

Thank you for asking and having our opinions in mind as you create this feature!

[AhabGreybeard]

@tiar

But I’m a bit worried whether making it possible for Assistant Mask to be attached to other Masks is a good idea… It breaks what users know about Krita (that masks can be attached to layers or groups but not other masks).

Maybe call it an ‘Assistant Overlay’ and place it above the layer (or mask) that it’s attached to, with an indent?

The word ‘mask’ in this context implies (non destructive) modification of the content of the layer wheras an ‘Assistant Overlay’ would be something shown as laid over the layer that does not affect the content but gives additional facilities (drawing assistants).

Additional thought: A Selection Mask doesn’t modify the content of a layer. It affects your ability to perform operations on a layer. Maybe it should be called a ‘Selection Overlay’ with an overlay style of presentaion as I described

[raghukamath]

It can be shown like any other mask but there is no need to call it as a mask. it can be just called “Drawing assistants” As in there is no rule that only masks should be in the sub layer category. Who knows in future there may be vector layer with sub-layers consisting of vector objects.

Give it a different icon instead of a thumbnail and have it attached to a layer like local selection masks or have it shown a top in case it is a global assistant.

[Troken]

I would like to add that the concept/term of “mask” is not intuitive and many newbies will probably not have an idea what it means. Can be confusing.

So if it is not necessary to use the term, then maybe we shouldn’t. imho

[Deif_Lou]

This is what I came with trying to visualize the feature.

It can implement assistant masks + ability to see and manipulate independent entries for each assistant in the mask:

• The masks would work just like @tiar explained. In the layers docker it is shown as a normal mask entry. They can have a “visible”, “lock”, and “active” icons.

• For the visualization/manipulation of the independent assistants, we have the classic “on-canvas” editing when the mask is selected. Then there could be any of the following (or both to satisfy everybody?):

  • Independent assistants directly shown under the assistant mask. The mask can be expanded like a group to show/hide independent assistants. Only assistants can be placed there (they are objects in the assistant mask, not real layers). If the user don’t want to see them or don’t want them to take space in the layer stack, then they just keep the mask collapsed.
  • Assistant docker: It shows a tree which contains the layers that have assistant mask, assistant masks and the independent assistants under the assistant mask entry. This would be like a filtered view of the layer stack explained in the previous point, but outside the actual layer stack.

  In the list, the individual assistant entries would show the “visible”, “locked” and “active” icons as well. Showing the independent assistants is important to allow the user to move them between assistant layers, duplicate and remove using the layers docker buttons, etc. It is also useful to manipulate the assistant then various assistants overlap on the canvas in a messy way.

  As side note, any of the listed points can be applied to other types of layers that work with multiple manipulable objects. For example, vector layers could expand to show the list of shapes, or colorize mask could expand to show a list of scribbles. So I would try to make a generic implementation that could be reused in the future if needed.

• I would not allow nested assistant masks/layers. Maybe something similar to the assistant docker (tree) option can be achieved just by allowing multiple assistant masks on a layer.

• Regarding the naming, I agree that using the term “mask” for everything is confusing. That’s true for every current “mask” type except for the transparency mask. I would change that naming to in favor of “local layer” or something like that:

  • Transparency mask → Transparency mask (or simply mask)
  • Filter mask → Local filter layer
  • Colorize mask → (local?) colorize layer
  • Transform mask → (local?) transform layer?
  • Local selection → local selection
  • Assistant mask → local assistant layer

[postmax]

Assistant masks are like Clip Studio Paint. I do like the general idea, but it can be hard to locate the assistant in the layer tree. Perhaps the assistent layers could always be at the top, taking up the space of 1 layer, with the possibilty to open up the layer like a tree? It would need to collapse automatically. You would not need an extra docker and it would take up less space.

[Deif_Lou]

Another option of kind of having the assistant docker and layer docker integrated would be adding advanced filtering options to the layer docker. That way one can select “assistants” and the stack would show only those, maybe still in a tree form that show the parents.

[AhabGreybeard]

@Deif_Lou

• Transparency mask → Transparency mask (or simply mask)
• Filter mask → Local filter layer

I agree with the principle of what you say in this area but the Filter Mask can be painted on to affect the ‘strength’ of its function in the same way that a Transparency Mask can be painted on.
A Transparency Mask can be thought of as a Filter Mask that performs an alpha x 1.0 function with strength multiplied by its greyscale content.

The curent ‘Selection Mask’ can also be painted on but it doesn’t (non-destructively) affect the content of the layer it’s attached to. It affects other functions such as painting, copy, etc.

[nickgeneratorfailed]

Please just not another docker. If the functionality can be added without creating a new docker such as the mask options I think it should go that way.
Number of dockers on screen is increasing while screen space remains the same, also think about android devices, new docker just for this while it can be kept inside layers docker might not be a good solution for mobile devices.

Well, I’m mostly talking here about screen space, not just as a personal preference (and it is) but it hopefully makes sense. In comic panesl connecting it though masks/groups rather than going through a separate docker will also make the use more straighforward.

Great work on the assistants, you’ve been steadily improving and everytime bringing something interesting.

[Takiro]

I really like the idea to have assistants like a mask, this would solve two major issues I currently have. Grouping them logically and more importantly grouping them locally for example with comic panels. (Also copy and pasting groups of assistants, probably)

Bonus points for making it possible to move all assistants by using the move tool on the mask or group/layer with that mask (use case: change the order of comic panels on a page).

And if the assistants are automatically hidden when you choose a layer they don’t apply to, that would be the icing on the cake.

However I see a downside when I have an assistant mask on a top layer group but I don’t want to apply it to all subgroups. This could be difficult to solve because of different user expectations regarding the behavior.

To have an overview of the available assistants in a project an additional tree view in a docker would be helpful I guess. Especially for navigatio, if you can click on a node and it selects the mask for you in the layers docker.

[LunarKreatures]

The idea of assistant mask is really great, to me it makes a lot of sense for comic book workflow and having the flexibility of using global assistants is a plus over CSP.

Though not really following why some people are discussing changing masks names, to me this is unnecessary. A mask is something attached to a layer and in this sense it works perfectly, calling it a " local layer" is much more confusing imo. At least to me, calling it a layer and making it behave like a mask doesn’t make any sense so i am against any name changes in that regard.

I also think an assistant list is useful do people can quickly select a certain assistants especially if they opt to use the global assistants. And having it on the tool options docker would be ideal in my opinion as it’s most times already visible

[tiar]

@LunarKreatures

And having it on the tool options docker would be ideal in my opinion as it’s most times already visible

The downside is that it would only work with the assistant tool selected.

[LunarKreatures]

@tiar

The downside is that it would only work with the assistant tool selected.

Yes but unless you can set which ones are active to be snapped to in this docker i don’t really see much use in it being a complete separate view from the tool options. If you can then yes i think a docker could be more useful for quick switching.

[raghukamath]

@LunarKreatures

A mask is something attached to a layer

No, A mask is surely attached to the layer but its primary function is to mask the parts of layer with a grayscale image as the mask. We do have a exception of colourise mask. Assistants will not have any such things. It is okay to have it in place of masks and we do not need to add or label it as masks.

People get confused by trivial reasons, I am not sure if they will not be confused by assistants being called as masks.

[wpfosh]

My vision has always been about the assistance tree in tool options. As an example, drawing a city where houses are located at different angles. Each needs its own vanishing points. And probably there are several assistants for cars and characters. Even clouds… Here it would all be grouped. And turn it on/off as a whole group. Moreover, a group with a clear name and color.
This is also great with presets. Turn on the preset, you immediately see the layers.
The option with a separate docker is also tempting. But it seems logical that in order to do something with assistants, you need to turn on the tool for them. Or not? Hm… I don’t really see a convenient workflow with the creation of assistants in one window, and work with their sorting in another. I don’t have much space in my workspace.
Local assistant masks are also a great idea. But they are local of course. You can’t turn them on and off all at once if they are on different layers and groups. These are two different ideas with the assistant tree

[LunarKreatures]

@raghukamath

No, A mask is surely attached to the layer but its primary function is to mask the parts of layer with a grayscale image as the mask.

Technically might be, but honestly if we look at transform masks this already breaks down from the user point of view. As you are not painting anything in grayscale from the user point of view, you are transforming something.

So to me makes much more sense to understand masks as something that you attach to a layer, as this definition fits all cases. Might be wrong in a technical sense but it’s what makes more sense to me.

However my point was toward people discussing changing names for all the current masks to " local layer" and that i don’t agree. To me it’s best to leave names with mask as it’s behavior is analogous to the transparency mask.

Btw for assistants they can just be called assistants or guides. I just think calling them anything like local layer won’t have meaning to most people. As no other software has such concept creating new names for things that can be called something else makes it harder for people to understand imo.

[raghukamath]

@LunarKreatures

I just think calling them anything like local layer won’t have meaning to most people.

I agree. The assistants can be shown along with other masks. the layer can have thumbnail or it can have a icon in thumbnails place. The name can be simply “drawing assistants”.