A1111 scripts

[guzuligo]

There are some img2img scripts which would be very useful to use with this, especially the ones that change the output image.

Isn't it possible to have a tab for the scripts as well? If not, is there a way we could help develop ones? The ones who have the skill could even create ones specifically for openOutpaint.

[guzuligo]

I wonder if it is easier to implement an option to trigger whatever script active in the img2img tab. This would be sufficient to some degree ... except for the ones who want to modify their script settings a lot, I guess.

[seijihariki]

The only problem regarding scripts is that, as far as I know, there is no way of fetching available scripts from the API. Maybe I'm wrong... @zero01101 probably knows more about this.

Also, after getting script information, we will need to display some type of interface to input script parameters. Still, we can look into it, and even possibly submit a pull request to the webui adding script indexing support. But it may take a while to implement.

[zero01101]

same, to my knowledge there's no way to get a list of scripts (and far more importantly, their parameters) from the API; merely using one via the API is only officially 2 days old :/

[guzuligo]

Krita plugin did something to get the scripts. I think maybe you can find it here?? https://github.com/Interpause/auto-sd-paint-ext/blob/main/backend/script_hack.py

[seijihariki]

The issue with that is only that it relies on the gradio script loading, so it would not work for openOutpaint unless it was running as an extension.

We would have to basically disable all script controls if we are not running as an extension, and that data would have to pass through window-iframe messaging. that would really not be optimal.

When I finish the rotate/stamp scale things I can try developing a simple API endpoint for the webui and open a pull request.

An alternative (but very much a hack) would be to fetch / and read window.gradio_config from there, but I really don't want to do that.

[guzuligo]

Alternatively, if you can make something to send to img2img, the user could just run scripts on the part they need scripts with.

[Maki9009]

yes some scripts such as loopback would be great for this.

[Maki9009]

Honestly loopback would be the only script i need... it would be perfect and that's it.

[seijihariki]

I have been testing for a bit, and quite sincerely, it has been quite hard to fetch parameters due to them being only defined as gradio blocks.

Either we manually implement handling for each type of block (even then, certain functions, such as expand areas will probably not be detectable if they implement JavaScript), or allow the user to pass a custom json object manually (PaintHua style config).

Will keep looking into it.

[zero01101]

or allow the user to pass a custom json object manually (PaintHua style config).

hah, kind of ironic you'd say that as i hadn't even considered it until this comment and now i think it might be a pretty solid workaround until there's an actual API endpoint for querying scripts/parameters; going to be taking a bit of a cue from https://github.com/mix1009/sdwebuiapi#scripts-support regarding run() parameters beyond self and p when i get around to trying this out, but my current idea is "script support will be entirely manual and used at your own peril and risk, we can't provide any support for scripts, much less their parameters beyond maybe checking that you're submitting a properly formatted JSON object"

[zero01101]

ok well in the interest of full disclosure and the tradition of "i'm an idiot", i've got it passing arbitrary data to the request because that's easy enough, but testing it against scripts is... annoying.

if anyone wants to git checkout manual-scripts and screw around, press the [~] (or backtick but i can't seem to escape backtick in markdown lol) key to pop open the manual scripts panel.

title expects ... script title, e.g. X/Y Plot

i think script args list expects a comma-delimited list of values e.g. Steps,5-50 [5],CFG Scale,2.2-16.7 [5],true,false,false but it yells about

  File "E:\storage\stable-diffusion-webui\scripts\xy_grid.py", line 430, in run
    x_opt = axis_options[x_type]
TypeError: list indices must be integers or slices, not str

and again, i'm an idiot, i don't know python, etc :|

[seijihariki]

From your error, it is probably that the script itself uses an index of the options in the list for X/Y plot instead of indexing the actual value (it uses a select element with numbered options).

[zero01101]

sadlol i sure tried manually indexing them but please see previous idiocy :D

[seijihariki]

Oh, weird, will give a look when I'm at home.

[guzuligo]

Not all the scripts have to work. As long as some of them function, the rest could come gradually whenever you have time for it.

For me, scripts like the loop script might be the most important as it really adds value to the outpaint tool. X/Y ... not much.

[Maki9009]

yeah specific scripts would be be more ideal.

[seijihariki]

We could actually have a "hard coded" list of supported scripts - that is, just a json file that contains a list of scripts/parameters - and if anyone wants a new one to be added they can open an issue.

[guzuligo]

As a temporary workaround, this is extremely helpful. I have a script I am working on. I could just edit the json file to use.

[seijihariki]

I think I found the issue in your implementation, @zero01101... From what I see, you were splitting the text in the box and feeding it properly into a list, but you were sending the data as is, thus sending a list of strings:

What we need to be sending here is every value in its proper format (first and third are integers, and should be parsed as such. Last three are booleans, and so should also be sent as JSON booleans.

@guzuligo okay, will try doing that for now then.

[seijihariki]

Okay, passing the correct type args worked:

X/Y Plot is a bit weird with it though haha

[Maki9009]

Ooo Ooo Ooo test test Loopback pls

[seijihariki]

Seems to have worked as well.

[Maki9009]

Ooo, it works but its broken, but its works

[zero01101]

but you were sending the data as is, thus sending a list of strings:

🤦 one day you'll all believe me when i warn of my terminal stupid lol

for what it's worth, i'm WAY more into a script-agnostic args input panel like it currently is than hardcoded options as that's an unending pandora's box of everybody's favorite script needing its own definition which i guess isn't that big a deal if they're ok with writing their own definition for their favorite script? either way, thanks for fixing my bad work yet again lmao

[seijihariki]

but you were sending the data as is, thus sending a list of strings:

facepalm one day you'll all believe me when i warn of my terminal stupid lol

for what it's worth, i'm WAY more into a script-agnostic args input panel like it currently is than hardcoded options as that's an unending pandora's box of everybody's favorite script needing its own definition which i guess isn't that big a deal if they're ok with writing their own definition for their favorite script? either way, thanks for fixing my bad work yet again lmao

That would probably be fine. We can actually check for script existence. We can store script info in the local storage as well for not having to set up every time.

[seijihariki]

But I guess we could provide some out-of-the-box configuration to support built-in scripts from auto1111's API.

[zero01101]

yeah, i'm definitely fine with that given how much i've been wasting time just playing with loopback lmao

[zero01101]

added a few "sample" configs for 3 scripts that seem potentially useful just as a starting point :) params for available preloaded scripts have tooltips for, uh, something similar to convenience?

[zero01101]

"implemented" in https://github.com/zero01101/openOutpaint/commit/c0e936f2166e8d055a88a30911d57d7094a79a74, a little janky but the manual should give you a good start :)