[Feature Request] Turning OpenOutpaint into an A1111 Extension #109
Comments
|
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. |
|
We could probably achieve complete integration sending resources between the two interfaces using messaging, actually. |
|
@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. |
|
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 i'm sure you'll be shocked to hear that i've never used |
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.
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. |
lmao you will shortly discover that it is not ;)
sure is :| super bonkers, right? invited you as a direct collaborator to https://github.com/zero01101/openOutpaint-webUI-extension :) |
|
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 |
|
Are submodules automatically downloaded on extension clone? If so, I agree. |
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. |
|
Added issue for discussion of implementation for the extension on the separate repository: |
|
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 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 👍 |
|
Is it already working from local install or does it still use GitHub pages? |
|
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/ |
|
ooooo <3 might replacing with |
|
Should do the same. If you prefer, ./res also works. |
|
aha, seems not as much as i'd like :| |
|
Oh, the css are really loading relative files from their directories? That's... Suboptimal. Will probably have to refer to ../../res then. |
|
In the upside, probably no duplication will actually need to happen for configuration.html to work. |
|
yep, just tried exactly that for files in lol uh guess i'll merge that to main since
|
|
🎉 |
|
@wywywywy do you know how it works to add an extension to the main webui repo? Do we have to request it somewhere? |
|
Yea you gotta ping @ClashSAN to get your extension added to this page: https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Extensions-index |
|
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 |
Oh, okay! @wywywywy Give it a look now. It should be mostly working. |
|
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:
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. |
|
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. |
|
Yea you're right. Saving metadata is not all that important so let's forget about that for the time being |
|
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. |
|
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 |
|
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] |
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
|
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) |
|
For the model stuff, I'm thinking of disabling model changing from the openoutpaint ui and updating model text display from the messaging system. |
|
definitely agree that just disabling the model selector in the openOutpaint extension is probably the safest and most "obvious" way to do that |
|
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. |
|
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? |
|
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 |
|
@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. |
|
WE IN THE BIG LEAGUES NOW 🎉
|
|
Well done lads! |
🎉🎉🎉 |
|
think i can probably safely close this issue now ;) |
Is your feature request related to a problem? Please describe.
OpenOutpaint is a great idea. But having to run another app does not make the workflow seamless.
Describe the solution you'd like
Add OpenOutpaint as an extension to A1111. This will become a new "Outpaint" tab in the A1111 UI.
Describe alternatives you've considered
I guess you could edit the
webui-user.batfile to run both A1111 and OpenOutpaint at the same time, but it is still not really seamless.Additional context
It should be simple (I think) to build an iframe in a tab. So the changes to the codebase shouldn't be too big.
In the future it could have additional features such as sending a generated image from the "txt2img" tab to the "Outpaint" tab.
The text was updated successfully, but these errors were encountered: