My conclusion from research for now is that Medibang's comic panels are way too underwhelming, and CSP's code architects know what they're doing. I was surprised they made the comic panels layer into a group layer ("folder") but it makes perfect sense, and even more sense in Krita: group layers have their own projection, and they calculate it from the children + the backdrop. There is nothing there that says they couldn't first draw the backsides of the frames, then the frame content, then the borders. Or that it couldn't cut the content from outside of the frames.

I'm now a bit worried I could suggest myself from their solution too much, because it just makes sense and I don't have any other good idea right now. But I will continue thinking about it.

Questions are:

• what exact complex structures comic artists can have? (most probably both borders and background should be optional)
• what are the needs? where Krita should come forward and help? - outside of painting the lines in a precise way - I mean "inherit alpha"-like feature etc. - should it be optional as well?
• wouldn't CSP's way be a bit too limiting? (note the need to put all lines for just one panel in a group)
• more later

There's a lot to think about here, so it's hard to even know where to begin!
I think you've done a lot of good research and I agree with your conclusion that something along the lines of what CSP can do is the right direction for this feature.

To summarize my understanding of the big picture, it seems to me that comic panels are basically arbitrary vector shapes.
Panels can be arranged in relation to each other (preserving evenly spaced gutters) OR overlapping.
Panels usually mask layers of image content, but there are times when content needs to pop out from panel.
Panel shapes can be divided/cut and transformed in various ways, and care should be taken to preserve panel/gutter alignment when we can.
Panels should be able to render a brush-based border or not.
Panels should be able to be treated like an assistant, and manually traced.
And so on...

So... there's a lot of ground to cover for this feature.
Having talked with @eoinoneill about this, we did come up with a couple of thoughts:

1. Because panels are basically vector shapes, it might be a good idea to start with the knife tool for splitting vector shapes. I think this could be done elegantly with a tree structure of shapes, but it'll take really digging into the code to see if that's true. Once we have that, a "Panel Layer" (or whatever) might be just an extension of a Vector Layer that also acts like a Group.

2. Another prerequisite is being able to use (or convert) an arbitrary vector shape as a transparency mask.

I don't know too much about how vectors are handled in Krita yet, but there's probably gonna be some kind of interaction between KisShape and KisMask, which exist in pretty different parts of the KisNode inheritance hierarchy. (Or maybe a refactor...) I think the difficulty here is that the new type of layer that we're describing here is one that shares traits with vector layers, transparency masks, and groups. (Maybe it could be a special type of group that we can also draw vector shapes on? Hard to know right now...)

3. For manual tracing of panels, another requirement might be a new assistant type that allows for brush magnetism with vector layer object outlines. This is probably lower priority but may be worth at least thinking about ahead of time.

Things like whether a panel border is drawn or not, whether space for a gutter is kept or not, those things can just be per-panel settings that we can worry about after the core mechanics are figured out.
Overall I think it's a really exciting project and will be a great tool for comic artists. :)

edit:

there are times when content needs to pop out from panel

Actually, lets not overthink this... I think having a character pop out from a panel is really as simple as creating a regular new paint layer *on top* of the panel layer/group, and then painting the character over the panels.

I could read all, very good research @tymond .
I really like the modulable features idea of @emmetoneill and @eoinoneill (the three bullet points in previous post).

1. [...] the knife tool for splitting vector shapes

A knife tool (that support a thickness, for gutter size) is an excellent idea.

The challenge with vector, imo, is how a traced vector shape could be transparent by default to be a panel content (boundary of a shot) and have a border. It's possible right now to do that only after adding a 100% opaque shape that fills the canvas, and then tracing smaller shapes on the top with "Logical Operation > Substract". But that's a lot of click, setup, and difficult to get alignement right.

So, maybe a special vector layer type 'in negative' compare to usual vector layer could be necessary to render each vector shapes on it as transparent panel content.

@Deevad I do intend to do this "modular design", yes :) Knife tool is one of the most important parts I plan to do actually. It's present even in Medibang. It's so basic and so useful that it just must be done.

I remember I gave you a link to this task when it was still in the research state, have you read the rest that I added yesterday? All after "Current idea"?

I actually didn't want to share the link again just yet because I wanted to create and add more pictures :)

The challenge with vector, imo, is how a traced vector shape could be transparent by default to be a panel content (boundary of a shot) and have a border. It's possible right now to do that only after adding a 100% opaque shape that fills the canvas, and then tracing smaller shapes on the top with "Logical Operation > Substract". But that's a lot of click, setup, and difficult to get alignement right.

So, maybe a special vector layer type 'in negative' compare to usual vector layer could be necessary to render each vector shapes on it as transparent panel content.

So I did actually thought about this "negative space" thing but I decided not to do that, because it's quite common for artists to actually make something I called in my notes "background panels", which means the background is itself a panel. This is a good example: https://krita-artists.org/uploads/default/original/3X/b/8/b8f596844f2e817cdfcfc7054f2403a43bfb0a67.jpeg . So, the panel cannot affect the areas around the panel (unless stated otherwise :P ). See also this: https://krita-artists.org/uploads/default/optimized/3X/5/f/5f139d46bc3fb8791ed28aead3fddebad9e2c63c_2_518x800.jpeg . Even a case of one panel being drawn over the other would not be really possible if we used the negative space idea. (Unless I misunderstood what you said).

Instead, I will use a mechanism similar to inherit alpha. My current idea can be deconstructed in *current Krita* in this way:

• user creates a group
• in a group, there is a vector layer with background shape(s), and another with borders
• the shape for background and for the border is the same, but the border one has only stroke and the background one has only a fill
• all layers created by the user are located over the background shape(s) and below the border shape(s)
• all layers created by the user are clipped to/inherit alpha from the background shape(s).

Example file:

The Panel Layer I will create will be much more convenient, because:

• you will need to only create one shape and Krita will take care of dividing it into border and background, and making sure your layers are clipped
• there will be less layers to take care of, because the background and borders will be somehow hidden/less accessible (I'm not sure how to do it yet - because users need to be able to edit them, too, but... well that requires more thinking :) )
• if the user changes a shape on the panel layer, both shapes will be changed simultaneously (unlike in the test file, where if you change one, you need to either change the other, or remove the other layer, duplicate the one you changed, and then change the fill and stroke) (unless user wants to edit them separately, to allow "spillover"... <- still needs more thinking)
• there are also plans for allowing raster borders, which will work the same way, even calculating the background shape using some smart algorithm deif-lou is making, or maybe Colorize Mask algorithm, or in the worst case just simple Fill Tool algorithm (unless the user wants to edit them separately again).
• since it's a custom layer, we could actually have *both* border and background invisible and layers could still inherit alpha from the invisible background shape.

What do you think about it? Do you see any important limitation that I haven't noticed? I did even try to address the workflow when people like to group sketch, color and inking separately, while doing all panels together, it won't be as nice as the panel-by-panel workflow but should be good enough, I think, at least in basic layout without overlapping panels.

ok, so I'm a little too fried by text-layout to give an indepth comment, but I wanted to note that our transparency masks can handle vector shapes, because they're based on KisSelection (as are filter masks and filter layers), which can have either vector or(and?) raster based selection. Krita doesn't allow editing vector selections on transparency masks, but if you make a vector selection, then create a transparency mask, and then save and inspect the kra file, you will see that Krita will have stored an svg file for the transparency mask.

What do you think about it?

Thank you for the details, example and the Kra file; I better see now.
Your proposal covers stacking/overlaping of panels and that's great.

Ping @rempt @dkazakov - hi, could either of you read through the "Current ideas" section of the task and see if it makes sense from the development point of view? I mean I'm sure it's doable, but whether it's a good enough idea? I want to ask for further feedback on KA, and then start implementing, and of course details of the plan can change at any moment (specifically, I want to figure out how to simplify it without sacrificing too much of usability), but I need to know if the foundation of the idea is okay (especially the Panel Layer idea and the "binding" of points in vector shapes).

for @Deevad:

stroke with brushes after creation

Theoretically, we could make a "vector shape" for that, but there are complications

wondering, how to make it possible for some things to go out of the frame?

One can just attach a transparency mask onto the panels layer

for @tymond:

"vector or raster" -> it's a bit like a Local Selection Layer, it can be either vector or raster

Theoretically, you can combine the two. You can create a special type of layer that has "vector shapes" inside, but renders their outlines with normal brushes on a KisPaintDevice. To achieve that you can follow the idea of vector selections. They provide a KoShapeManager interface for the tools, so normal vector tools can modify them. But the rendering happens without using the vector (srgb-based) rendering stack.

calculating backgrounds for raster borders happens when the user requests, maybe?

Why do we have to calculate them at all? We have generator layers, and they are generated only once (with some color-space-related complications). Can we just reuse them?

the frame borders and backgrounds layers must be somehow accessible to users but shouldn't bloat out layer stack

I would really prefer if this point would be combined with the "simple blue overlay" feature. That is, all these extra "layers" or "masks" would be hiddel in the layer's header line (like the "Fx" icon for the layer styles)

possibly later select a gutter and change the width? -> this must be done *somewhere*, here it would make sense, but how it could guess that it's a gutter and not something else?

Perhaps the whole frame should be a shape? Then it should have its own custom mode in shape editing tool, where the user could modify border/gutter width/style?

"spillover" - it's somewhat common for a comic artist to make most of the content of the panel to be inside the panel, but parts of it "spill out" over the background or other panels

We can try to allow the user to apply transparency masks to the panel. Though it will require you to change the layout of the panels layer stack. Right now you rely on the inherit alpha functionality linked to the background layer. But in this approach you will have you avoid that and clip the panel by applying the frame with composite-copy blendmode. Then the transparency mask (or something like a selection in KisAdjustmentLayer) will allow the user to override this clipping.

assistance on raster drawing borders

I guess we should also finally implement per-layer assistants. We do already have KisDecorationsWrapperLayer, so it can just be generalized a bit.

adds a layer to the panel that is alone on its panel layer. (so, the layer is a child of the firstly made panel layer).

Actually, I see two different approaches to solving this problem:

1. Make a "Panel Layer" inherit a group layer and modify its copyOriginalToProjection() method to do the blending. This group layer could have a selection (to override "spillover") and provide KoShapeManager to let vector tools communicate with it. I personally don't like this solution for two reasons:
   • It requires to create a group even for a single-layered panels
   • It doesn't perfectly fit into the technical design of Krita's layer composition process and can have subtle issues.

2. Make a "Panel Layer" actually a mask. This mask can either be applied to a group or a paint layer and do all the compositing needed. The mask can also provide a selection and KoShapeManager. And we need to implement mask-in-stack-visual-compression anyway.

3. [bonus option] Theoretically, you can also use KisAdjustmentLayer approach, which does all the blending in KisUpdateOriginalVisitor and blends the result using composite-copy blendmode. This approach is good for "Separating by sketch/color/inking workflow", but will create mess for all other workflows.

Note about workflow of the knife tool:

uses a knife tool to cut it into two. Uses option so that they are on two different layers.

I'm not sure that the knife tool should split that panel layer into two right away. It would be much easier for the user to do all the vector shape splits and then split them into different layers.

calculating backgrounds for raster borders happens when the user requests, maybe?

Why do we have to calculate them at all? We have generator layers, and they are generated only once (with some color-space-related complications). Can we just reuse them?

I meant calculating the area within the raster borders. If the user just painted their borders, we would still want to provide sane clipping of the content to the panel borders. See here: https://krita-artists.org/uploads/default/original/3X/b/8/b8f596844f2e817cdfcfc7054f2403a43bfb0a67.jpeg - I would like to support this kind of comics too.

the frame borders and backgrounds layers must be somehow accessible to users but shouldn't bloat out layer stack

I would really prefer if this point would be combined with the "simple blue overlay" feature. That is, all these extra "layers" or "masks" would be hiddel in the layer's header line (like the "Fx" icon for the layer styles)

Yeah, that was my plan. Something more like Colorize Mask, maybe, with custom buttons at the end, controlling the layer's parts?

possibly later select a gutter and change the width? -> this must be done *somewhere*, here it would make sense, but how it could guess that it's a gutter and not something else?

Perhaps the whole frame should be a shape? Then it should have its own custom mode in shape editing tool, where the user could modify border/gutter width/style?

I don't think that would work:

• it cannot be all panels as one shape, because some people like to make some gutters of different widths than others
• it cannot be one panel = one shape, because then, what is a gutter? it's a space *between* panels (so, between shapes)...

"spillover" - it's somewhat common for a comic artist to make most of the content of the panel to be inside the panel, but parts of it "spill out" over the background or other panels

We can try to allow the user to apply transparency masks to the panel. Though it will require you to change the layout of the panels layer stack. Right now you rely on the inherit alpha functionality linked to the background layer. But in this approach you will have you avoid that and clip the panel by applying the frame with composite-copy blendmode. Then the transparency mask (or something like a selection in KisAdjustmentLayer) will allow the user to override this clipping.

With inherit alpha approach you can allow the user to do it too, just by allowing them to edit the layer that that alpha is based on/inherited from.
But I'm not sure how the composite-copy blendmode would work here?

assistance on raster drawing borders

I guess we should also finally implement per-layer assistants. We do already have KisDecorationsWrapperLayer, so it can just be generalized a bit.

Yeah, I am even assigned to that, I guess I can just leave that task to when I'll be working on assistants..

1. Make a "Panel Layer" inherit a group layer and modify its copyOriginalToProjection() method to do the blending. This group layer could have a selection (to override "spillover") and provide KoShapeManager to let vector tools communicate with it. I personally don't like this solution for two reasons:
   • It requires to create a group even for a single-layered panels
   • It doesn't perfectly fit into the technical design of Krita's layer composition process and can have subtle issues.

What is the difference between having a group with one child and having a layer with a mask? In both cases it's two entries, one below the other. Both can be compressed to just one entry, too.
And in case of a mask, if you want multiple layers, then you'll have both the group layer and a mask, so one entry more.

Also, I wouldn't like a selection there, because that would be destructive. If you have inherit alpha or transparency mask (equivalent solutions here), you can draw outside of the panel and it isn't lost. So later you can move the content inside the panel, or change the panel shape slightly, and it won't need as much work to add the missing parts.
Moreover, inherit alpha or transparency mask work well with File Layers, so in a case where the user sets up panels and then adds a File Layer with let's say a background they often use, or even just the specific painting that they prefer to draw in a separate .kra file because it's too heave for Krita on their computer. Selection wouldn't cut off the excess content in such case, because it only works during the painting process.

2. Make a "Panel Layer" actually a mask. This mask can either be applied to a group or a paint layer and do all the compositing needed. The mask can also provide a selection and KoShapeManager. And we need to implement mask-in-stack-visual-compression anyway.

Hmm, interesting idea. Will have to think more about it. Also ask users, too.

3. [bonus option] Theoretically, you can also use KisAdjustmentLayer approach, which does all the blending in KisUpdateOriginalVisitor and blends the result using composite-copy blendmode. This approach is good for "Separating by sketch/color/inking workflow", but will create mess for all other workflows.

I'm not sure how that would work. Just like the mask, but would mask everything below? I feel like that would be the worst in terms of "how many entries in the Layer stack the user needs to have".

Note that by the "raster and vector" I originally meant just that the user can draw the border themselves using a brush. Of course gutters etc. wouldn't work, but the clipping itself could. Or alternatively, they would use the vector approach, but disable painting of the vector border (which I intend to allow) and draw the borders themselves on the layer above it.

Also I think I intended for the knife tool to work on all panels at once, even though they are on different layers? I'm not sure why. But yeah, in such case it would be better if the user first divides them, and then distributes.

Also note that this is partially based on what Clip Studio Paint is doing, they have the group layer approach, so if there would be no significant advantages of other approaches, it would be probably not a bad idea to follow their example because that would make both exchanging files (if we ever have CSP file format, or they have Krita's, or maybe if there is any other one...) and moving from one program to another easier. I based my design on theirs because I thought it was very smart, because you can put anything you want in that group and it will all work gracefully.

The problem is also editing the panels after you have them on different layers. But that's a common problem of all the approaches mentioned above, maybe except for that adjustment layer one. I think maybe we could just think of making it easier to edit vector shapes no matter the layer? Or, maybe only the panels would react? There could be an option in Tools Options for them (something like "edit panels, so ignore which layer is selected, just find any").

for @tymond:

the shape for background and for the border is the same, but the border one has only stroke and the background one has only a fill

There might be an issue with this approach. It is basically the same issue as layer style's stroke filter. The problem appears when the border line is painted semi-transparent, or if the line is painted with some brush that has "holes" in it (which is very probable for painterly brushes). It will cause two problems:

1. If you seperate the background and the stroke into a backdrop and an overlay correspondingly, then the user will see the border of the backdrop through the holes. You can theoretically workaround that issue by merging both, stroke and fill into the backdrop (making the stroke duplicated in backdrop and overlay). It will partially resolve the issue, but there will still be the next one...

2. [I'm not very sure about that though] If the stroke has transparency, then painting it over backdrop and/or panel content may create the "halos" problems. That is exactly what we had with the "stroke" layer style. The solution to that is to use "knockout groups" (in terms of PDF specification I linked to you recently) or KisKnockoutBlower (in terms of Krita). That is, the panel borders will not be painted with normal composite-over, but with a special tricky method.

If my second point is true, then teh whole idea of inherit alfa will not work and will be replaced with KisKnockoutBlower.

for @tymond:

What is the difference between having a group with one child and having a layer with a mask? In both cases it's two entries, one below the other. Both can be compressed to just one entry, too.

The difference is that you cannot paint on a group layer that has a child layer hidden/collapsed. But you can paint on a paint layer that has a mask hidden/collapsed.

And in case of a mask, if you want multiple layers, then you'll have both the group layer and a mask, so one entry more.

If you have a mask "hidden" into the group layer's line, it basically visually transforms into your idea with a group layer.

Also, I wouldn't like a selection there, because that would be destructive

I mean a different "selection". Each Adjustment Layer or Generator Layer has a selection, which works as an embedded transparency mask. If you decide to use KisKnockoutBlower, then you can somehow merge this selection into the knockout selection. Though there might be complications with overlapping... so we can probably just ignore this usecase as someone above suggested.

I'm not sure how that would work. Just like the mask, but would mask everything below? I feel like that would be the worst in terms of "how many entries in the Layer stack the user needs to have".

Yes, Adjustment Layers work exactly like filter masks, but filter "everything below". And, yeah, it is not teh best solution UIX-wise :)

Note that by the "raster and vector" I originally meant just that the user can draw the border themselves using a brush. Of course gutters etc. wouldn't work, but the clipping itself could. Or alternatively, they would use the vector approach, but disable painting of the vector border (which I intend to allow) and draw the borders themselves on the layer above it.

Theoretically, you could use the approach used by selections, which convert from vector into raster form as soon as the user starts painting on them. But I should say that it was extremely painful to implement :) And it will also be painful to reuse :)

The problem is also editing the panels after you have them on different layers. But that's a common problem of all the approaches mentioned above, maybe except for that adjustment layer one

We could think about storing multiple panels on the same layer and implementing some "isolate panel" feature. But I guess it would be a bit too cumbersome.

I think maybe we could just think of making it easier to edit vector shapes no matter the layer? Or, maybe only the panels would react?

That would be quite difficult from the technical point of view. You would have to make some aggregated KoShapeManager-based class (which is not polymorphic atm) that would aggregate shapes from all the panel layers.