[Feature Request] Turning OpenOutpaint into an A1111 Extension about openoutpaint HOT 43 CLOSED

It will probably be more suitable to make use of git submodules in the new git repo instead of trying to get git clone in python to work

from openoutpaint.

ok lmao wow that got really good at making me feel like a complete pillock lol

anyway, no more install script, submodules work finally, not "magically" installed unless you git clone --recursive or something, so i just added a submodule update routine to the script itself

definitely makes sense re: missing icons (and makes even more sense now that it's running off of the local submodule lol) but yeah, i'm not exactly sure what the best course of action is for that...

all that being said, it does seem to work as-is right now just by manually installing the extension from the repo url 👍

from openoutpaint.

Oh, the css are really loading relative files from their directories? That's... Suboptimal. Will probably have to refer to ../../res then.

from openoutpaint.

Oh god, it's almost scary how effective whatever he is doing is in finding extensions! The new repo was barely twelve hours old, and he included it in the wiki.

[edit]
Yeah, that last entry is quite unique in terms of Stable Diffusion webui extensions. Excited to see where that one goes. Not sure if we will have an update soon, though, considering the last commit date.

from openoutpaint.

1. It doesn't really need to ask the user for the server URL. It can just take it from the address bar because when acting as an extension, they'll always be the same

2. When doing "Send to openOutpaint", it should also send the prompt

These two are done. Need to see what we can do about model selection on openOutpaint (how we will handle changes in model on webui and openoutpaint). Sending to image is on the way. Will probably use the select tool for that functionality. (also need to fix some bugs on select tool with the layer system)

from openoutpaint.

For the model stuff, I'm thinking of disabling model changing from the openoutpaint ui and updating model text display from the messaging system.

from openoutpaint.

Well done lads!

from openoutpaint.

WE IN THE BIG LEAGUES NOW 🎉

🎉🎉🎉

from openoutpaint.

Could be a thing I guess? Haven't seen how extensions work but as we only need some basic hosting for some files, an iframe should work just fine.

Though updates may be a bit hard to apply depending on browser caching. Maybe add something to handle that.

Also should lock the host field and have a button to allow for iframe refreshing, as we don't really have a reset button for some functionalities (canvas expansion).

We should also not pollute the webui's local storage or IndexedDB, so starting some parallel file hosting would be preferable.

from openoutpaint.

We could probably achieve complete integration sending resources between the two interfaces using messaging, actually.

from openoutpaint.

@zero01101, what do you think? We can use a separate repo for this, I think, for the actual extension and python code involved. For communication with the webui itself, we can use messaging between webui and openOutpaint: https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage.

from openoutpaint.

hah, earlier this morning i actually tried messing with just a very remedial attempt at getting an iframe in there like suggested; my python is admittedly worse than my javascript, and i couldn't figure out how in blue blazes to get it to embed a git clone of openOutpaint, but just as a stupid test got the github.io-hosted one "working"... not sure where the tool icons went though...

but agreed, i definitely think it'd be its own separate repo; i've got the install.py successfully cloning openOutpaint to the extension's directory already but that's, uh, pretty "step one" kinda stuff :/

i'm sure you'll be shocked to hear that i've never used postMessage() lmao

from openoutpaint.

hah, earlier this morning i actually tried messing with just a very remedial attempt at getting an iframe in there like suggested; my python is admittedly worse than my javascript, and i couldn't figure out how in blue blazes to get it to embed a git clone of openOutpaint, but just as a stupid test got the github.io-hosted one "working"... not sure where the tool icons went though...

Hey, that's good! Can you try sending this to a new repo, so I can try doing it from there? And is the github-sites version of openOutpaint broken in terms of icon loading? That seems a bit strange to me.

but agreed, i definitely think it'd be its own separate repo; i've got the install.py successfully cloning openOutpaint to the extension's directory already but that's, uh, pretty "step one" kinda stuff :/

i'm sure you'll be shocked to hear that i've never used postMessage() lmao

Not really, as it has only some pretty niche applications. Primarily for inter-tab communication and parent-child iframe communication. I used this only once in my life for very basic stuff.

from openoutpaint.

Hey, that's good!

lmao you will shortly discover that it is not ;)

And is the github-sites version of openOutpaint broken in terms of icon loading? That seems a bit strange to me.

sure is :| super bonkers, right?

invited you as a direct collaborator to https://github.com/zero01101/openOutpaint-webUI-extension :)

from openoutpaint.

Are submodules automatically downloaded on extension clone? If so, I agree.

from openoutpaint.

And is the github-sites version of openOutpaint broken in terms of icon loading? That seems a bit strange to me.

sure is :| super bonkers, right?

invited you as a direct collaborator to https://github.com/zero01101/openOutpaint-webUI-extension :)

Just checked, this seems to be an issue of relative paths. openOutpaint, for now, assumes that it is being run on the server root, so it uses "/res" as a first part for icon loading. The thing is, if we use relative paths, the configuration page icons will break, as it is on another path. We can use "../res" for resources on the config page, but then we duplicate icon loading code, as CSS would not be able to be shared.

We could also move configuration.html from pages to root, but then we start filling the root with html pages... Not sure what is the better approach.

from openoutpaint.

Added issue for discussion of implementation for the extension on the separate repository:
zero01101/openOutpaint-webUI-extension#1

from openoutpaint.

Is it already working from local install or does it still use GitHub pages?

from openoutpaint.

local install via git submodule :D

from openoutpaint.

local install via git submodule :D

Then will have to use relative paths probably; shouldn't be too big a change to fix the images... Just a general search and replace of /res/ to res/, and custom css for the X on the configuration.html file referencing ../res/

from openoutpaint.

ooooo <3 might replacing with ./res/ be better?

from openoutpaint.

Should do the same. If you prefer, ./res also works.

from openoutpaint.

aha, seems not as much as i'd like :|

from openoutpaint.

In the upside, probably no duplication will actually need to happen for configuration.html to work.

from openoutpaint.

yep, just tried exactly that for files in ui/tool (and simply ../res for files in ui) and it seems to have worked :) just pushed that to testing

lol uh guess i'll merge that to main since

• it works
• the extension kinda needs it there
  

from openoutpaint.

🎉

from openoutpaint.

@wywywywy do you know how it works to add an extension to the main webui repo? Do we have to request it somewhere?

from openoutpaint.

Yea you gotta ping @ClashSAN to get your extension added to this page: https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Extensions-index

from openoutpaint.

Once done it'll probably be a good idea to go onto to reddit and promote it a bit. To get more eyeballs on it

from openoutpaint.

Yea you gotta ping @ClashSAN to get your extension added to this page: https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Extensions-index

Oh, okay!

@wywywywy Give it a look now. It should be mostly working.

from openoutpaint.

Ok I don't have much time right now, but after a quick test, I can say that it looks good!

For the first release, I think it needs a couple of changes to be complete:

1. It doesn't really need to ask the user for the server URL. It can just take it from the address bar because when acting as an extension, they'll always be the same
2. When doing "Send to openOutpaint", it should also send the prompt

And going forward, it'd be really nice to have the ability to send the canvas to img2img, so that the user can further process it (e.g. with SD Upscale). Maybe "Send to extras" too.

Another thing is when using the "Save" button, it doesn't save the metadata. But it's a general issue, not specific to the extension.

from openoutpaint.

Yes, I agree with most of the points. The host really should be locked, and send to img2img is on the way. This is most of a first look to check for basic functionalities and compatibility issues with other installations.

Save not saving metadata is a complicated topic... Considering what would happen when a downloaded canvas contains multiple generations, or even worse, multiple layers.

Even if we only implement this for image generation saving and/or generated resource downloading, this would need to be implemented as manual editing of the image binary exif data, which would be... Unpleasant to say the least.

from openoutpaint.

Yea you're right. Saving metadata is not all that important so let's forget about that for the time being

from openoutpaint.

Just open an issue for this metadata stuff so we don't forget. It probably will stay there for a while, but at least it is on a todo somewhere.

from openoutpaint.

kind of irrelevant but regarding the extensions index, seems @ClashSAN may somehow already be aware? https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Extensions#test seems to have come in on this commit

i'm a particular fan of the last entry and am very looking forward it its release :D

from openoutpaint.

Not sure if we will have an update soon, though, considering the last commit date.

MAN MY COWORKER ALWAYS GOES ON ABOUT "OH THIS REPO HASN'T BEEN COMMITTED TO IN 6 YEARS" and i'm just like MAYBE THAT MEANS IT'S PERFECT ALREADY

from openoutpaint.

definitely agree that just disabling the model selector in the openOutpaint extension is probably the safest and most "obvious" way to do that

from openoutpaint.

I think, in general, it's safe to consider the current state of the extension as fully functional and stable enough. We can ask @ClashSAN if there are any problems with the way we are updating our submodules and to add it to the main list. Also, create a simple README for the extension repo.

from openoutpaint.

i added a tiny little readme with a quick screenshot; it's pretty bare however :/ genuinely not sure if there's a way to ping someone on github aside from mentioning them like we've already done?

from openoutpaint.

It'd be a good idea to raise a feature request issue on the A1111 repo to get some visibility & tracking, to have it added to the wiki

from openoutpaint.

@wywywywy Seems like (at)ClashSAN (will not tag him to avoid sending too many notifications) has taken a look at our repo: zero01101/openOutpaint-webUI-extension#1 (comment)

Will keep this issue open for a bit, even if/after the extension is officially added, and close it after implementing proper model selection handling and send to img2img.

from openoutpaint.

WE IN THE BIG LEAGUES NOW 🎉

from openoutpaint.

think i can probably safely close this issue now ;)

from openoutpaint.