Option to revert back to an older version or to use the old highres fix

[user2734283]

Hello. Thank you so much for your work! I spent countless hours creating with openOutpaint and I enjoyed every minute with it. I lvoe the ui and the results, it is just perfect. Great work!

There has been some uproar in the A1111 community about the new highres.fix and a lot of people really hate it and revert back to an older version, I did that too. I was getting really upset when I saw that openOutpaint updates itself, so the new (absolutely brainless and stupid) highres fix changes are integrated into your UI. I tried replicating my old good results but I am just getting strange garbled results now.

Is there an option to revert my extension to an older version? I want to keep a functioning program and not be a victim to the absolutely unnecessary and abrupt changes in the A1111 repo. I was really sad to see that it made its way into your repo which I loved so much.

The latest commit in the A1111 repo makes it possible to specify resolutions again, which is very good news. PLEASE give us the option to just "use old highres fix" so I dont have to play with the options for hours to get a normal result

[seijihariki]

I get the frustration (even though I do not normally use HRFix). We can try writing some compatibility code, but while AUTO is changing things, new versions will keep breaking functionalities for a while. Oh, and @zero01101, did you see auto's latest commits? - specially AUTOMATIC1111/stable-diffusion-webui@8149078; Not sure if it changes anything for the API.

[seijihariki]

@zero01101 Do you think we can add a semi-blackbox for this - automagically detect new/old API and change HRFix code accordingly?

[zero01101]

sigh part 2

so to preface, i personally think the new hrfix is a "better idea" in the sense that it's less likely to have user input error; firstpass height/width being effectively "backwards" was always awkward, but i also get that it's a breaking change for a lot of instances.

my initial plan was to just drop a repo for a "legacy hrfix" extension that wouldn't ever really get updated, it'd just stay at 0.0.12.3 forever, but i agree that trying to keep both methods available and using the appropriate one is preferable but i promise anything i commit will be ugly; the new implementation still scolds you for passing firstphase_width/height parameters and uses those values as the new desired resolution returning literally half-res "downsampled" garbage. i literally just noticed all the chaos and haven't even TRIED the new A1111 commits yet, just searched the repo for firstphase and noticed the admonishment is still there.

[seijihariki]

Considering the ugliness of the issue in question in the first place I think we don't really need a beautiful solution! Still, I can try giving a fallback (disable hrfix inputs and send width/2) for when this error crops up.

[user2734283]

I knew this repo would be in some disarray as soon as I saw the commits about the hrfix rework. Thanks for putting in so much work and going through so much frustration, Im amazed. I think I have to be a bit more patient perhaps or just figure out some settings I can work with. Hrfix was important for me in use with outpainting because the classifier free guidance sometimes needs a bit more information from a picture, so I would increase the resolution or use a bigger height than width. I could 512' everything but it can be difficult for some scenes.

[seijihariki]

@user2734283 if you could give the hrfix-compat branch a try...

[user2734283]

Yes I will try it! Thanks for being so helpful

[seijihariki]

@user2734283 HRFix compat now on main. (It uses the old algorithm of half the current gen resolution for first phase)

[zero01101]

@user2734283 just so you're aware, this compatibility patch unfortunately only works on "outdated" versions of webUI, nothing newer than AUTOMATIC1111/stable-diffusion-webui@fd4461d - current versions outright disallow the old method of passing parameters and yeah, as mentioned, completely misuse them from my experience... i should probably compile some evidence and file a bug report about that because i bet we're not supposed to be punished for using deprecated params...

ANYWAY all that being said, don't expect the old controls without an old version of webUI to match :)

[edit]

a lot of people really hate it and revert back to an older version, I did that too.

🤦‍♂️ just noticed that part sigh

i should probably compile some evidence and file a bug report about that because i bet we're not supposed to be punished for using deprecated params...

unfortunately i can't get this to happen with bare API calls to webUI so i bet this is actually my fault ha ha ha what a surprise

[user2734283]

@user2734283 just so you're aware, this compatibility patch unfortunately only works on "outdated" versions of webUI, nothing newer than AUTOMATIC1111/stable-diffusion-webui@fd4461d - current versions outright disallow the old method of passing parameters and yeah, as mentioned, completely misuse them from my experience... i should probably compile some evidence and file a bug report about that because i bet we're not supposed to be punished for using deprecated params...

ANYWAY all that being said, don't expect the old controls without an old version of webUI to match :)

Thanks a lot! Couldnt try it yesterday will try it today.

I just saw that A1111 is removed from Github, but on Reddit they say the extensions list is working again. He set up new camp on "gitgud" which is a rather sluggish feeling copy of github. The chaos is ... evolving

edit: and its back online again: https://github.com/AUTOMATIC1111/stable-diffusion-webui

edit2: trying out OpenOutpaint on my old version and I think it works pretty well again. Will also set up another version with the newest update and "research" the new hires fix and upscaling options further