Add ability to save clipping masks in PSD files and make it cross compatible as much as possible

I actually agree on the usability aspect as well, but I just wanted to be clear my primary motivation in bothering devs for layer clipping masks/2nd mode for inherit alpha is cross-compatibility, since I can make do with inherit alpha within Krita exclusively just fine. Even when I was clear about this, I still got this in return:

So you can see why I immediately refrained from citing usability as another reason for implementation.

Anyways, your proposal aligns with my proposed solution as well, I agree completely.

Personally, I would like for that to be extended to have a choice of layer targets.That’s what I want to see in Krita.

Do you mean a random set of layers/groups or a given number of layers below the one selected?

Inherit alpha is pretty much one of the few things that stops me from using Krita in professional settings (where many people work on the same file) and from suggesting Krita to other people. The system pretty much works (the end result) about the same as other programs, but with more steps, while also making files incompatible.

Some kind of automated system to make the folder/layer structure more compatible with PSD and translating inherit alpha as clipping mask into it would be really great.
Ideally a change to the inherit alpha system (which was discussed here as well) will probably be even better, because it both would make the system more sensible (especially for people transitioning to Krita from another program) and compatible.

1 Like

The second one with the catch of not just bottom, but top too.

I made such a model a few days ago: we can set the color of the layer, and then inherit the alpha according to the color. If there are multiple layers, blend them.
At first I just felt that there were too few colors that could be set. Later I found out that this would disrupt the mixing order of krita’s layers. krita now calculates the images in the group first, and then blends them from bottom to top. If the upper layer is set, it is difficult to determine how to calculate it. Moreover, if you nest each other, I think it will cause serious bugs…

Yes, some serious sanity checks would need to be in place. So you can’t for example cross-inherit alpha between layers. Or you can’t inherit alpha from a group the layer in question is part of.

I’m not 100% sure this would be a good idea.

@hulmanen Good point, and having such options would require a lot of time to pull off. Ideally, we would have something like this with some issues fixed there and there due to the flexibility this mode would have.

@TheTwo That’s what I’d like though I would like to be able to specify a single layer to use as alpha base as well. Sort of something of what you can do by clone layer and Destination In Blending Mode. You can adjust which layer to use in Clone Layer properties.

I find all these ideas to be better only by giving compatibility to PSD the most stupid ideas ever. Krita is not a free Photoshop and should not fight for it the least bit what it should be is to be better than not replacement of the subscription because this is what this proposal is at its core.

It should instead improve ORA file format to help transfer information openly and better. That will win this interchangeability issue.

Going after Adobe that does its best to stop everyone trying reverse engineer their file format. Is useless the next year they will just change things again and all work will go to waste.

I have seen these fights in the 3d world and only a truly open source file format can make the bridge it is why ILM made all their formats open to use for the whole industry. The ones are not only last as the champion program is still the champion ergo PSD.

All this fight over some pixels colours that are the same everywhere not even built different or different technologies. E vender a banha da cobra.

While some people want this, I personally came here to suggest improvement to inherit alpha. Not for compatibility for PSD, and yes ORA should be supported, but there are zero incentive to do that as long as GIMP does not come with NDE.

1 Like

Hm. I’ve addressed the exact same points umpteen times at this point. Let me try to lay this out as clearly as possible:

My original feature request was for layer clipping masks to be implemented into Krita. In my OP, I (wrongly!) assumed PSD compatibility wasn’t an issue, since Krita already had export/import capability. Therefore, the only needed addition to solve the compatibility, in my mind at the time, was to add layer clipping masks to Krita.

Many then pointed out that PSD compatibility was in fact an issue. However, that made it clear that greater compatibility was a dual-pronged topic:

  1. Layer Clipping Masks are needed
  2. Better interchangability with a common format is needed (PSD)

My original request was only concerned with point #1, because I wasn’t even aware of #2. So, #2 is technically beyond the scope of what was being suggested, along with PSD vs ORA or whatever file format you prefer. Everyone and their mother wanted to chip in on why they hate PSD, so we got quite bogged down in that. But again, it was actually beyond the scope of the original request, which is how we ended up in “just do everything possible to improve cross-compatibility” territory. Which I think is the best move altogether, BUT if PSD support is not possible, I think it’s important to keep the original request in mind, which is something others here with no interest in cross-compatibility have also expressed interest in.

What is this GIMP NDE?

Why is everyone derailing into #2 then? I spent 10 minutes readding about PSD only…

Like when I propose to add commands to the already current ones and everyone talks about me wanting to replace the current layout commands.

Stay on topic at least guys.

Krita can makes its own workflow if it improves I am cool with it. I have no opinions over clipping masks compared to what already exists. I am good either way.

1 Like

Non-destructive editing?GIMP seems to implement them by version 3.2
In addition, mypaint seems to have made some changes of its own to ora when implementing spectral mixing.
As the functions implemented by different software become more and more exaggerated, compatibility seems to be a very troublesome problem. I am pessimistic that maybe only outputting the “result” is the final outcome. That is, when exporting the file, only the basic layer structure is retained, and the characteristics of the software itself are all merged… :fearful:

1 Like

IDK man, we’ve been in “just do everything possible to improve cross-compatibility” territory for so long now (as you can see the title even matches now), that I really don’t blame you at all, it’s just frustrating lol.

Admittedly I didn’t do well at all to keep it in scope either, inquiring into every issue raised the way I did (inherit alpha vs layer clipping masks, why PSD can’t/shouldn’t be compatible, ORA, etc.).

NDE is non-destructive editing. Without GIMP having NDE, there’s no incentive to support ORA.

1 Like

Unless I’m mistaken, GIMP doesn’t have layer clipping masks or inherit alpha either, correct? So the cross-compatibility would be at least equally bad as PSD currently is anyway, right? Can ORA even transfer the information of such clipping systems into other apps, that hypothetically will support it in the future, if GIMP doesn’t even have said systems?

I’m all for ORA conceptually as I’ve said, but there are current problems that require current solutions if cross-compatibility is to be improved.

Damn, this thread is getting worse and worse :smiley: I thought the discussion was done like a week ago, but the comments number grows and grows…

So here’s what I’m going to do: I’m going to close this topic. I will open two new topics: one for clipping mask compatibility with PSD/Photoshop, one for improvements for inherit alpha in Krita. Now you have an opportunity to add your last words, and I’ll be closing it and add the links to the new topics and then please do stay on topic and don’t talk in circles (which I noticed happened in this topic quite a few times).

I hope that no one minds it, and I hope that it will make the discussion a bit more productive, too.

If anyone wants to open an ORA improvements topic, please do so, just make sure that it doesn’t start to discuss things that are being discussed in other threads… just stay on topic.

7 Likes

The topics I created: