No the title was “Layer clipping mask” it no way describes what you wanted. You can have written “Add layer clipping mask as in photoshop” And the solution to add different mode came up now after much discussion.
I changed the title because every person who saw the title was writing some other feature request about clipping mask which was no way related to the original discussion. the title was too generic and broad. Please write specific title.
And we are just trying to come up with a solution for people who have workflow like you so there is no irony here. Other than implementing the new mode we don’t see any easy solution other than the python plugin solution suggested.
The irony is that we are back exactly where I started. Is that not humorous? Sheesh
On the contrary, the title described exactly what was wanted. “Feature request for layer clipping masks” entirely encapsulates what I was asking for. Call it another mode for inherit alpha or whatever you want, but what is being described is literally implementation of layer clipping masks.
I never wanted it to be “as in photoshop.” I was clear about this. I think it should have the capabilities of programs like CSP (clipping to and of groups), but having greater seamless compatibility with PS through voluntary avoidance of such clipping relationships.
I understand the need to change it as a result of attracting other unrelated feature requests, I was just pointing out how it’s come full circle.
I already outlined how the python plugin doesn’t solve much at all, especially for how much work it sounds like it would involve. Most structures that would need translation are impossible. Therefore, only deliberate avoidance of such structures can allow for export anyways, and import doesn’t require anything more complex than the automated grouping and conversion of clipping mask enabled layers to inherit alpha that I suggested, or alternatively, this new layer clipping mask mode for inherit alpha.
I said from the beginning that a new mode would be useful for me. I don’t really care about psd, but I think that if clipping to 1 layer is implemented, then it is worth it trying to load/save clipping masks from/to psd since it becomes easier (in terms of features) and a lot of people uses it.
(The following assumes we know how to decode the layer mask info from a psd, which seems it’s not true at the moment)
If that mode is implemented, then loading is easy I think: if a psd has a group just create one in krita and set the pass through according to the psd group. If a layer has clipping mask then set in krita the new inherit alpha (clip to 1 layer).
Saving is more difficult because you have features you can not export to psd. And I think the best real solution is to warn the users on exporting and leaving to them the decission of making a psd compatible document or not. The users should know what they are doing. If you want to use psd as an interchange format then you should limit yourself when editing the document. Then Krita just would save the groups with the same pass through and save the layers with the new mode as clipping masks. If unsupported features by psd are used, then just warn the user on saving/exporting.
That’s what I would do.
LOL, sorry if that’s too liberal of an interpretation of “Feature Requests > Layer Clipping Masks”
I don’t know what to say anymore man, I’ll just leave it at that.
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.
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.
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.
@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.
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:
Layer Clipping Masks are needed
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.
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.
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…
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.).
