Layer export needs batching and trimming option by default

[EviTRea]

Gamedev and YouTuber here.
It’s common practice to paint a whole image, and then export layers separately, then piece images together in another application.
Krita has layer export, but has a few issues…
1.Hidden in the “Layer” context menu, while “File” would make much more sense, since we’re generating a new file here.
2.Can only do 1 at a time, which when multiple layers are needed, makes us manually do something machines are particularly efficient at.
3.Export them at project resolution, even if the layer is a pixel. It can make sense when the relative position matters, but more often then not, I’d need the assets be in the center of the image so rotation would work.
(If the layer is bigger than the canvas, it would actually spit out the resolution of the whole layer…but the image only contains the part that was on the canvas. WHY.)

These are by no mean a deal breaker for anything, and can be done with a plug-in or another batch-converter script, but I believe these are not technically difficult to implement, and can drastically improve UX on exporting.
Like, currently, I’d ctrl-click the layer, trim the whole image down with selection, export the image, then use ctrl-z to revert the image trimming. It’s…I don’t want to put it in another way, it’s just stupid.
And, while I’m at it…I never see why would the “Export” option defaults to another .kra file. If I want another kra, I’d just “Save as”. Why would I be defaulted to spitting out project files?

So, my proposal is:
1.Remove “Export/Save” in the Layer context.
2.Add “Export Selected Layers( as Images)” in the File context, maybe also to the right-click on layers menu.
3.Have options to (1)combine the image or separate them, (2)In Canvas or Layer Content.

Maybe also an option asking if FX should be applied temporarily, so that things like outline won’t be cut out because it’s technically not part of the layer?
I’m getting ahead of myself, I’ll stop here and wait for feedback.
Thanks for reading.

[YRH]

I think this is a reasonable enhancement, but probably the main challenge is making this universally useful. I can see people wanting to customize the export settings in various ways, so the UI for this feature could get complex. So that sounds like a plugin could be a better fit here after all.

Even if it’s just a “one click” export all layers cropped, that can run into some difficulties like how to name the files (avoid conflicts if the layer has the same name?), and whether it is a problem that relative canvas position of the layer is lost (if you crop it, how do you put it back in the right place?). So I see issues like that which make it more complex than it seems at first. It may be non-issue for you, but it could be for someone else.

[EviTRea]

I think this is a reasonable enhancement, but probably the main challenge is making this universally useful. I can see people wanting to customize the export settings in various ways, so the UI for this feature could get complex. So that sounds like a plugin could be a better fit here after all.

You have to draw a line somewhere, or with that logic, we can also ask colour wheels to be plug-in since we can draw in monochrome and people have drastically different approach to colours.
Yes, we can’t have a pre-made solution for every single possible use case, but the whole point of an app existing, is to have some pre-made solutions for someone. It’s never a problem of “Whether or not”, but “How much”.

that can run into some difficulties like how to name the files (avoid conflicts if the layer has the same name?)

That is indeed a problem…well, we can just use layer name as default solution, and put _n behind if the name conflicts.
If that doesn’t suit some people’s need, they can resort to plugins; If enough people have problem or someone proposed a better idea, make adjustment later.
I don’t think it’d be technically expensive to iterate out a solution of naming exported files, we don’t have to be THAT careful taking the first step.

whether it is a problem that relative canvas position of the layer is lost (if you crop it, how do you put it back in the right place?)

I don’t think it would…?
First of all, why would Krita do the “Crop the canvas, export, revert the crop” workaround? Can’t it just take the data in the layer and render it?
Let’s just say it can’t, it needs to crop the whole canvas for every export, what’s the engineering problem for that…?
I mean, the thumbnail of a layer only contains the part that has pixels, so I’d guess a layer was already “Image+position” in the first place; but if it’s not, temporarily storing some Vector2 data and retrieve it later…would that really be a problem for a developer or computer that can handle the whole Krita in the first place?
Or maybe they’re all problems somehow…then just don’t modify the project file during the export, make a shadow copy and free it after export finishes…?
I’m armature in programming, but I really don’t see the issue HERE.

I see issues like that which make it more complex than it seems at first. It may be non-issue for you, but it could be for someone else.

I agree I can always be overlooking complex issues, it’s the nature of feature request, one can only see as much through the lens of a user.
But I really can’t get your point, from both technical standpoint and a UX one.

Technically, aside from transparent-cropping and FX applying, my proposes are just rearranging existing functions.
If some of those are hard-coded in a way that doesn’t allow rearranging without huge refactoring…That’d be a way bigger problem that I can’t comment on.

From UX perspective, if the button turns out to be horrible, people can…just not use it?
It’s not really disruptive to an existing workflow, we can resort back to the manual way if it doesn’t pan out.
If someone really need the layer export to be in layer context somehow, leave it in and mark it as “Legacy, will be deprecated”, and we can at least get some conversation going.
I’m aware that this mindset runs the risk of bloating the menu…but let me point out that we already have an “Export Advanced” option that does nothing but adding a resize option. This, I’d ask whoever needs it to get a plug-in, because I really struggle to figure out a use case for it.

All those being said though, it doesn’t seem like anyone was exited by the idea so far, maybe I AM an edge case, and I won’t really complain if my issue doesn’t get prioritized.
That’s all I have to say. Thanks for reading this far.

[YRH]

No, I only mean the exported files that you will get will not have relative canvas placement information. You won’t be able to “put it back together” from the PNGs alone. I’m not worried about anything on the Krita side.

What is your use case then? I presume it’s not a painting, but more something like game assets?

Otherwise, I think this should be easy to implement as a basic “export all layers” feature.

[EviTRea]

No, I only mean the exported files that you will get will not have relative canvas placement information. You won’t be able to “put it back together” from the PNGs alone. I’m not worried about anything on the Krita side.

Well, that’d be weird to be brought up in the Krita forum, but sure, I can talk about it.

What is your use case then? I presume it’s not a painting, but more something like game assets?

Game and animation, yes. The reason I’d want them to be exported was to not have them baked in, so I can move things around later.
Say I have a house as the foreground and background, and a character will walk out of the door.

I’d want to paint them in a single canvas, so I can easily have consistent proportion under the same resolution. (Drawing in different resolution and scaling them afterwards makes inconsistent imagery, and it’s hard to keep track of the proportion only using math.)
Part of the house would block my moving object, then the object would block the house, since they’ll be moving, I can’t just export the whole image, I’ll need at least some of the layers informations;
Precise position wouldn’t be that much of the concern in these cases. As long as the blocking is logical, good enough is enough. If I really have to, I can just export the whole image and use it as a reference.

The other thing about exporting layer without canvas data is what I briefly mentioned: When the layer is bigger than the canvas, it got crops out. (And the file is still the size of the layer, that’s probably a bug.)
I mean, I also don’t see why people would draw out of bounds instead of creating a bigger canvas, but hey, that’s another potential fix…though admittedly kind of reaching and may create more problem.

Personally, I’m fine if best I can have is the current whole canvas thing. It’s not a problem for me to run mogrify -trim +repage *.png one time and have everything perfectly cut on border.
My real issue is just the layer export got hidden in a weird place while “Export Advanced” takes a spot in the File context, and the lack of batch export. All the other things are just nice to have.

That’s about it. Thanks for reading.