This is very slow for large images, better approach is to insert mask as transparency layer: https://api.kde.org/krita/html/classTransparencyMask.html.

Currently working on this, but can't find a way to import this class to the script. Doesn't seem to work from krita module. No error is shown but it messes up the whole plugin.

Edit: nvm, found the way.

Hello. It seems Google Colab has changed their ToS to prohibit the use of remote UIs. This means I'm unable to perform testing and use the plugin, so unfortunately I'll have to stop development in this implementation. Anyone interested can rescue it and follow development.

that's so unfortunate :(

is it possible for you to use Runpod instead of colab @JasonS09 ? it's generally affordable to use, and i can even sponsor your GPU hours if you want

Hey, thank you for the offer. Honestly, I don't want to pay for this since I'm broke (got 17 dollars in my bank account, no incomes). If you say you can sponsor that could be an option, but I'm not sure if that service provider allows remote connections to the UI. Last time I tried in Paperspace, I couldn't use it as backend (simply didn't work even with the --api flag), and after a while I got kicked from my session, then unable to login again. I'm suspect they banned me for trying to use the UI as backend.

EDIT: I reinstalled webui in my local machine, and it somehow works better now. It's still really slow, but I think this will do the work. I'm going to be away this weekend, then I'll continue the work.

* Creating a transparency mask with `self.doc.createNode(name, "transparencyMask")`  in `script.py` is not working properly. It creates a node but you can't do anything with it (not really a transparency mask).

* `self.doc.createTransparencyMask(name)` doesn't seem to be a thing, even though you can [find it in the documentation](https://api.kde.org/krita/html/classDocument.html#abbd8e5ca62dd2952623c2d5cbc6faf5f).

* Alternatively, it is possible to create one by calling actions `self.app.action("add_new_transparency_mask")`. However, you seemingly can' use `setPixelData()` [to draw the mask into the mask layer](https://api.kde.org/krita/html/classNode.html#a4e0b624db748aa8cf63ba84131dfc1a7). Or at least all my attempts have failed to do so.

* So this only leaves me with one option I can think of: create a paint layer first, set the mask pixel data, then convert it into a transparency mask. However, there is another issue with this approach. Setting active node with `self.doc.setActiveNode(layer)` will work but not for the actions like `self.app.action("convert_to_transparency_mask")`. They will completelly ignore the current active node even if it's explicitly set. Making it really difficult to work with.

Well... I've independently verified most of these.

On my most successful attempt so far, where I attempted to retrofit transparency_mask_inserter(self) to handle these masks, I managed to get four functioning transparency masks on a batch and wrote data to one of them, though it did not appear correct, possibly because it needs to be converted to grayscale first? I did that by passing the mask all the way in that function and putting it right after add_mask_action.trigger() which is far less than ideal... I suspect that the issues you're encountering with setting pixel data on a layer created through app.action are more related to the race conditions that the inserter function is meant to work around, though, based on this experience.

I'm going to see if I can set pixel data on masks without completely butchering the mask inserter function, I'll let you know if I find anything out.

I've made a pull request on your branch for a partially working implementation... It is not very clean, mostly due to being shoehorned into old API code.

self.app.action("add_new_transparency_mask") does work, it does produce a correct transparency mask layer. But it does this on another thread, so if you try to immediately set the pixel data that causes a race condition. You also have to convert it to grayscale for it to write correctly, which isn't really documented explicitly anywhere. So my provisional solution, add the transparency mask to the layer, wait for it to appear, then write the data.

If you inpaint from a selection, with "Add transparency mask" enabled, it will work. However, the second that you touch one of the layers, the inpainting mask will be overwritten with solid white. It can be proven that it actually works by converting one of the layers to a paint layer, you will see the proper mask data that way. Why it gets erased when you unhide the layer or its parents, though, I have no idea -- perhaps it has something to do with the method of trying to work around the race condition by recursion. Once that is solved through whatever means (most likely by moving this into its own function and simply waiting for there to be a new child layer), that'll be a working implementation and one merge blocker down. I will try to work on it more later to see if I can make this into a fully working implementation.

This API is going to give me nightmares. I see references to the issues with the other methods of adding transparency masks from years ago, and we're stuck with the one that causes a race condition.

I've made a pull request on your branch for a partially working implementation...

Can you point me to it? I can't find it.

I've made a pull request on your branch for a partially working implementation...

Can you point me to it? I can't find it.

I seem to have opened the pull request on my own fork... Should be fixed now.

I figured it out. Fully working implementation.

setPixelData on a node is broken for some unexplainable reason. But you can setPixelData on a Selection, and then call to create a transparency mask... because the selection will become the content of that mask. This also seems to handily make every race condition irrelevant.

I am going to clean it up a bit, and then I will PR what should be a complete implementation