experimental? newer hrfix stuff

[zero01101]

so this adds the new HRfix functionality like setting desired output resolution and 2nd-pass step count, and they work and stuff but like i don't really know if they're useful at all here.

to preface, there are 2 new inputs for "desired output resolution x/y" and a HRfix steps slider. the steps slider is fine and isn't important here. the x/y inputs completely override any supplied value for scale if either is >0 and herein lies the problem.

just like the latent upscalers crashing if they're used against an inpainting model which doesn't seem to be a prevalent issue, setting a desired output resolution also completely fails against inpainting models. even if you're using a traditional model, setting a non-square output aspect ratio results in pretty trash output if you inadvertantly use a square reticle, etc etc pebkac whatever, i'm a pessimist :|

i've tried making a local "override settings" branch to specify a non-inpainting model on the first shot which worked as expected, but the internal webUI call reverting those override settings happens BEFORE the HRfix upscaling, so the upscaling tries to run against the inpainting model making it entirely useless.

anyway i have no idea and my brain is melt

is this even worth committing? like i'd rather give people the flexibility but this just seems to almost fight how openOutpaint... works

[edit]

i think i'm an idiot and just rubberducked my being an idiot; hold please, further commits incoming

[seijihariki]

I will give this a look, no doubt! But we may want to delay merging anything closely related to hrfix things for the next few days, as Auto may decide to change more things.

As I am not a frequent user of the HRFix function, and as such don't really know in any level very much of how it functions, I will have to give it a deeper look before properly reaching a conclusion on these changes...

For now let's just leave it as-is (with sensible defaults for most settings) and keep it simple. When hrfix updates calm down on the webui repo, we can continue this crusade!

[seijihariki]

Still, keep working on this if you are enjoying it! Maybe not much is changed anymore and we can just merge this branch when the time comes.

[zero01101]

hah, yeah, i stepped away and got some dinner and came back and started plugging away again and i just don't think it's happening tonight lol; at least it's not BROKEN against the new API anymore, and thank you again enormously for bringing back legacy compatibility too <3 i'm pretty sure that we're not going to need manual HRfix output res x/y inputs because literally all they do in oO is destroy pixel aspect ratios unless you get them spot on against the reticle, so i'm playing with setting those against the boundary box but also against the lock px value and also considering the liar checkbox and yeah i think i need to revisit this tomorrow lmao

like i'm 80% certain lying to HRfix is practically identical to setting an output resolution in webUI but CERTAINTY ELUDES ME

[edit] it is, for square resolutions of course -_- might be solvable by adding a "lock px to both axes" toggle for the lockpx slider... kinda glad i added that

ANYWAY whatever lol i'm going to bed, auto made WAY TOO MANY MERGES AND COMMITS today for me to even begin to wonder what else is broken lmao

thank you for everything once again, good night

[zero01101]

i obviously failed to go to bed but i am doing so in like 4 minutes but it at least can make the same picture as webUI with the new square aspect option that isn't even pictured here but WHATever gnite

[zero01101]

aright so the square aspect option is really useful, but there are most definitely caveats with HRfix and inpainting models/openOutpaint in general, with the first three issues being experienced in webUI directly:

• latent scalers don't work at all with inpainting models
• non-square output aspect ratios don't work at all with inpainting models
• not really inpaint model-specific but non-square "portrait" aspect ratios are utter trash through latent scalers
• openOutpaint can't exactly do bonkers things like firstpass 256x1024, resize to 1280x640 and probably never will

so basically, if you're trying to do something weird with HRfix, probably best to do so directly in txt2img interface where there's more granular flexibility, then send the result to openOutpaint and keep on keepin' on.

also, i really tried to use the override settings to optionally swap in a non-inpaint model for the initial txt2img dream, but yeah i guess that endpoint was initially meant for the actual settings - search for override_ - and the model switching was implemented via PR, so i guess i'm not too surprised it doesn't respect setting an upscaler too or anything :/

ANYWAY that being said, this works pretty well now given the above caveats. if you're just making square-ratio images, leaving "lie to HRfix" enabled and just turning on the HRfix option with scale set to 2 generally works pretty great for just making larger-resolution dreams. non-square ones work fine as long as you switch to a traditional model but it's kinda hard to forget when it bombs out trying to upscale it every time :/

the above example reproducing a non-square image from a square firstpass uses these settings:

so basically, square firstpass takes the larger of the firstpass x/y values and uses it for both axes. it's probably most useful with the HRfix lockpx slider which for the above example was set to 512 to clamp the seed image to 512x512. lockpx still works pretty much the same as it did in the manual for v0.0.12.3, except now the word "autoscale" is in there because it automatically sets the scale factor. it does some pretty remedial math to keep everything inline and i bet it's all quite inefficient and lazily implemented, but it seems to work fairly decently against the new HRfix stuff (which i also admittedly hardly ever used; probably used it more in the last 4 days than in the last 3 months lol) bringing it to a pretty usable state for openOutpaint use i feel.

side note, it might be placebo, but i SWEAR i get less of the weird VRAM vs 3D processing lockups if i zoom waaaaaaay out on the openOutpaint canvas?!? probably placebo...

[zero01101]

few more minor changes to where the divided scaling happens, seems pretty stable as long as the caveats are acknowledged, manual (including collaborator credits <3) has been updated, will update readme to call out new HRfix gotchas, gonna just YOLO merge this and see who complains ;)