Is it possible for the Forge version to be added?

[HumbleStranger]

Hey there, this extension is one of the best I've ever used and it's a must have for all inpainting editing-related needs. Although Auto1111's WebUI was a gold standard for a while, it's fairly outdated. Having switched to Forge I've discovered inference speeds and overall capabilities to be far superior and something I didn't even know my machine was capable of dishing out, but the problem is that your extension doesn't work with it and I get the following log whenever I try to use it:

Traceback (most recent call last):
File "C:\Stability Matrix\Packages\Stable Diffusion WebUI Forge\modules_forge\main_thread.py", line 30, in work
self.result = self.func(*self.args, **self.kwargs)
File "C:\Stability Matrix\Packages\Stable Diffusion WebUI Forge\modules\img2img.py", line 169, in img2img_function
mask = init_img_with_mask_fg.getchannel('A').convert('L')
AttributeError: 'NoneType' object has no attribute 'getchannel'
'NoneType' object has no attribute 'getchannel'

So, as the title states, is it possible for the Forge version to be added, or at least I would like to know whether I can fix it on my own somehow(I am not a coder, so I have no idea).

[PladsElsker]

Hey, I'm glad the extension has been useful to you!
Sure it can be done, but the problem is that it's incredibly hard to support multiple UIs at the same time.
The amount of time I have to invest in maintainance is like quadratic with the amount of UIs supported simlutaneously or something 😅

By the way, I have this exact extension as ComfyUI nodes in my files somewhere, I could share that if you are interrested.

If you want more details on this issue, it comes from the small library I made for uniformalizing the hijacking of img2img operation modes, sdwi2iextender. Essentially, if extensions add new operation modes like this extension under the img2img tab, but in unregulated ways, then you get extension conflicts 100% of the time, hence why some sort of API that handles the boilerplate is needed.

This is not the first time people bring this issue up.
Not sure yet how to tackle this to minimize maintenance, but I'll see what I can do.

[HumbleStranger]

If you want more details on this issue, it comes from the small library I made for uniformalizing the hijacking of img2img operation modes, sdwi2iextender. Essentially, if extensions add new operation modes like this extension under the img2img tab, but in unregulated ways, then you get extension conflicts 100% of the time, hence why some sort of API that handles the boilerplate is needed.

Mulling over this, I got a question: is there any reason why it wouldn't be possible to add a whole another tab like some extensions do, aside from cluttering the tab space? So on one hand we have a version that is compiled for A1111 that can handle in-img2img process perfectly fine, and on another hand we have a separate tab version that would avoid any and all conflicts with other operations, which in result would be highly compatible with customized frontends like Forge?

[PladsElsker]

Mulling over this, I got a question: is there any reason why it wouldn't be possible to add a whole another tab like some extensions do, aside from cluttering the tab space?

Yeah I think that's a valid workaround. The least annoying way from a maintenance point of view would be to create an accordion for it with all the other extensions. The only downside is that it makes the UI so much less intuitive to use. The way A1111 or Forge are designed, all initial masks and images that go into the img2img pipeline are defined at the top of the UI in what they call operation modes. Injecting the UI anywhere else will add a lot of back and forth for the user experience, and I would like to avoid that as much as possible.

I could add an option in the settings to let the user decide where the UI should appear, effectively ignoring the sdwi2iextender lib if it's not displayed as an operation mode. What do you think?

[HumbleStranger]

I could add an option in the settings to let the user decide where the UI should appear, effectively ignoring the sdwi2iextender lib if it's not displayed as an operation mode. What do you think?

Oh, so basically to have both options in a single package? I didn't think it was an option, but if it's a valid approach - it would be amazing. Both sides would be able to get what they want, and in case if one option doesn't work - they would be able to switch to a different one in the meantime.

[PladsElsker]

To give you an ETA, this will probably take a few weeks to do, as it's not my top priority right now. Probably something like early january.