stable-diffusion-webui
stable-diffusion-webui copied to clipboard
AUTOMATIC1111
[Feature Request]: Bring old Hires.Fix back
Is there an existing issue for this?
- [X] I have searched the existing issues and checked the recent builds/commits
What would your feature do ?
Newly implemented "Hires.fix" is:
- Very buggy (often producing doubled body parts)
- Time consuming - slow - not everyone has 4090
- causes often "out of memory" errors - don't forget people with lower VRAM - not everyone has 4090
- as you can see in bugs,discussion on reddit and here, makes problems: https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/6750 https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/6747 https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/6654 https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/7002 https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/6875 https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/6307 https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/6217 https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/6509 https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/6749 https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/6807 https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/7059
So PLEASE BRING BACK OLD Hires.Fix which:
- was working GREAT
- was faster
- was not resource hungry (no "out of memory" errors)
- was generating consistent images which you could always upscale later in img2img tab
Proposed workflow
- Go to to txt2img and use "old Good" Hires.Fix
- Press generate
- enjoy results
you can move/integrate "new hires.fix" or "old" as Extension script - so everyone could use it if he wants.
Additional information
Old good version: https://github.com/AUTOMATIC1111/stable-diffusion-webui/tree/e672cfb07418a1a3130d3bf21c14a0d3819f81fb https://github.com/AUTOMATIC1111/stable-diffusion-webui/commit/e672cfb07418a1a3130d3bf21c14a0d3819f81fb
git checkout e672cfb
If you learn how to use it properly, the new version is very good. Also, have you tried looking through the settings and using the options given to you there?
I Use the newconfiguration of "Hires Fix" from the start, and I have never noticed any of the grievances you mention, out of thousands of renderings. So, learn how to use the program, and leave the developers alone.
I don't think there's any harm in having an option for the old hires fix. I think it'd be a good idea to have the option.
I Use the newconfiguration of "Hires Fix" from the start, and I have never noticed any of the grievances you mention, out of thousands of renderings. So, learn how to use the program, and leave the developers alone.
hes right tho and you sound like a twat. i get good gens out of both but the new implementation is slow af and i never got cuda errors using the last version, or black squares for that matter.
So, learn how to use the program, and leave the developers alone.
Like some others (see discussion) I have "learnt how to use the program" and also experimented with it but the new algorithm is not giving me the results that old one did.
I'm all for it. I like the many updates and features this repo receives from its diligent dev but the new hi.res fix isnt one of them.
I'm getting much better results with the new highres fix than I did with the old one.
Please post prompts, model used, settings used and example pictures of the results before and after, to try and reproduce and see what the issue is
I left my testing and settings and thoughts on https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/6509#discussioncomment-4660801
I still think a toggle option between the old and new fix would be the best way to go.
yes im also after not fixing whats not broken and the new hiresfix broke it, some users fail to realise not everyone has 4090... id keep the new one as extension if it would be up to me
I Use the newconfiguration of "Hires Fix" from the start, and I have never noticed any of the grievances you mention, out of thousands of renderings. So, learn how to use the program, and leave the developers alone.
The problem is that this program gets updated so far, the damn wiki cant keep up, and new features and added so fast its hard to "git gud" when you have no idea what the new stuff does.
Bring back the old hires fix as the new one I have ZERO use for so it is a dead function for me.
So sad we lost the actual good highres fix. I find the new one fine or even better for simple things like portraits and landscapes, but it creates a lot more duplicate mutations when trying complex poses compared to the old one. My way of dealing with it was having the two versions installed, but it's not very practical.
Hmm so I have issues with vram using because that new highres?.. If so then I will also vote to return the old version. Because it just not normal I have 12gb vram and it's not enough now even for 720p arts.. Before update I was have no any problems with generation or large res arts 1500x1200 1900x1000. Just.. Not everyone have 3090/4090 cards for real!
UPDATE from my side:
After recent updates done to A1111 new Hires.Fix seems to work much better in my case but still some people may have need to use old one? Ps. I have tested it with a completely new installation (deleted old folder and did new git clone not just update) of A1111. Some other thinks seems to work bit faster also.
So if someone has problems, maybe this will help. Please, give your option after testing new hires fix with NEW installation (so we don't bother devs unnecessary) ;)
UPDATE from my side:
After recent updates done to A1111 new Hires.Fix seems to work much better in my case but still some people may have need to use old one? Ps. I have tested it with a completely new installation (deleted old folder and did new git clone) of A1111. Some other thinks seems to work bit faster also.
So if someone has problems, maybe this will help. Please, give your option after testing new hires fix with NEW installation (so we don't bother devs unnecessary) ;)
Updated client and still have a problem. RTX3060 12gb. 1024x1024 using more than 12gb and it ends up with ”out of memory”. No idea what's problem I reinstalled python again and CUDA drivers and still same.
After recent updates done to A1111 new Hires.Fix seems to work much better in my case but still some people may have need to use old one? Ps. I have tested it with a completely new installation (deleted old folder and did new git clone) of A1111. Some other thinks seems to work bit faster also.
Updated client and still have a problem. RTX3060 12gb. 1024x1024 using more than 12gb and it ends up with ”out of memory”. No idea what's problem I reinstalled python again and CUDA drivers and still same.
I have 8GB VRAM and above settings are working, but I have made new installation not update to get fully fresh env and other things. With 102x1024 I get also ”out of memory”...
But still getting some doubled body parts which was not the case in old hires fix, so we still need "body" or "consistency" fix :)
New "Latency Hires.Fix" x 2 - no words...
Reinstalled windows completely. And still this thing.
Steps: 20, Sampler: Euler a, CFG scale: 7, Seed: 3760877372, Size: 888x880, Model hash: fe074149ff, Model: SethAI Time taken: 18.38sTorch active/reserved: 6817/9098 MiB, Sys VRAM: 11396/12288 MiB (92.74%)
The interface of the new highres fix is miles better than the old one that required you to fiddle with the size and firstpass sliders all the time. I wasn't actually aware that the functionality changed though, other than addition of the Latent upscalers (but those are optional).
The interface of the new highres fix is miles better than the old one that required you to fiddle with the size and firstpass sliders all the time. I wasn't actually aware that the functionality changed though, other than addition of the Latent upscalers (but those are optional).
Doesn't work. I can take a prompt I did before the change that is larger (say 1280x512) for 2.x. I would only touch the denoise and 99% of the time no doubles or other weird stuff, but now it acts as if I never even activated it. I never really played with any of that slider nonsense.
The interface of the new highres fix is miles better than the old one that required you to fiddle with the size and firstpass sliders all the time. I wasn't actually aware that the functionality changed though, other than addition of the Latent upscalers (but those are optional).
Doesn't work. I can take a prompt I did before the change that is larger (say 1280x512) for 2.x. I would only touch the denoise and 99% of the time no doubles or other weird stuff, but now it acts as if I never even activated it. I never really played with any of that slider nonsense.
What do you mean "never played with slider nonsense"? Then you never used it. The old highres, after enabling it, required you to slide the size sliders to the desired higher size, and slide the first pass sliders to the smaller size. So say you were earlier making a 512x512 image. And you want to highres it 2x. You had to:
- enable highres
- set both size sliders (that were 512) to 1024
- set both firstpass sliders to 512 (though I hear that leaving them at 0 treated them as 512x512, maybe?)
If you never did that, then you would generate still a 512x512 image, technically higresed from a 512x512 one (as those were defaults if you left it at 0).
Now you just literally check "highres" and the defaults are to upscale 2x, so you don't have to do anything more.
The fact that the algorithm changed is an separate issue and I have nothing to say to that, but interface-wise it's much, much better.
EDIT: I'm now wondering if some people are confused because they thought just checking that checkbox with the old highres did anything if you didn't up the size yourself. It didn't.
EDIT2: I can also do 512x512 -> 1024x1024 highres on my poor 980 with 4GB VRAM just fine (and the results are good), so I think this is more complicated issue than just the "new" highres taking more vram.
EDIT3: Made some corrections as I didn't know the old highres defaulted to 512x512 firstpass if you left it at 0. I recommend people read that: https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/6509#discussioncomment-4627341
Don't tell me I never used it. I said I never played with that stupid slider nonsense as I left them at their defaults. I rendered at whatever the eff I did and without checking the box I ended up with horrors, multiple people, etc... I check the box and for shits and giggles moved the denoise slider to 0.65-0.67 and redid it and the horrors were gone AT THE RESOLUTION I RENDERED AT not upscaled. I prefer to do my upscaling in another app.
I will repeat I rendered at 1280x512, or 384 and sometimes 256 a shit ton, and without the high res fix (before that was even a thing too) it was a mess most times so don't tell me I never used it.
edit: "EDIT3: Made some corrections as I didn't know the old highres defaulted to 512x512 firstpass if you left it at 0." Yes, in 1.5 but to be honest I didn't need it as much in 768 V2.x. Then I needed it but the change had been done and it just didn't work. Whatever the defaults were for 0x0 is what I used as you can see in my old prompts using png info.
Don't tell me I never used it. I said I never played with that stupid slider nonsense as I left them at their defaults. I rendered at whatever the eff I did and without checking the box I ended up with horrors, multiple people, etc... I check the box and for shits and giggles moved the denoise slider to 0.65-0.67 and redid it and the horrors were gone AT THE RESOLUTION I RENDERED AT not upscaled. I prefer to do my upscaling in another app.
I will repeat I rendered at 1280x512, or 384 and sometimes 256 a shit ton, and without the high res fix (before that was even a thing too) it was a mess most times so don't tell me I never used it.
Highres does upscaling by definition. Just the old one did from whatever you set as firstpass to whatever you had set as your output resolution. (if you didn't set firstpass then it was from 512x512 it seems) In my opinion it's a less intuitive than the new one, but if you want you can get the same exact behavior with the new one, explained in the post I linked.
I always prefer thinking in terms of making, say, a 512x512 image and highresing that to 1024x1024, so the new interface is much better for me.
Sorry for the "didn't use it", I assumed originally that leaving the firstpass sliders at 0 would mean it would upscale from 0x0 (which would render it pointless), but it seems it defaulted to 512x512.
Don't tell me I never used it. I said I never played with that stupid slider nonsense as I left them at their defaults. I rendered at whatever the eff I did and without checking the box I ended up with horrors, multiple people, etc... I check the box and for shits and giggles moved the denoise slider to 0.65-0.67 and redid it and the horrors were gone AT THE RESOLUTION I RENDERED AT not upscaled. I prefer to do my upscaling in another app. I will repeat I rendered at 1280x512, or 384 and sometimes 256 a shit ton, and without the high res fix (before that was even a thing too) it was a mess most times so don't tell me I never used it.
Highres does upscaling by definition. Just the old one did from whatever you set as firstpass to whatever you had set as your output resolution. (if you didn't set firstpass then it was from 512x512 it seems) In my opinion it's a less intuitive than the new one, but if you want you can get the same exact behavior with the new one, explained in the post I linked.
I always prefer thinking in terms of making, say, a 512x512 image and highresing that to 1024x1024, so the new interface is much better for me.
Sorry for the "didn't use it", I assumed originally that leaving the firstpass sliders at 0 would mean it would upscale from 0x0 (which would render it pointless), but it seems it defaulted to 512x512.
Yeah, that 0x0 always threw me for a loop from day one. Now that I work with 768x768 native it stumps me.
Seems new changes have some problems with memory - week old commit works fine, with last changes often runs out of memory even with lover settings. Before i used to resize: from 448x704 to 896x1408 (x2), but now even resize x1.3 - can run out of memory
Same problem but with very inconsistent behavior. Pop_OS! 22.04, 3070ti laptop, nvidia-smi tells me only 4mb of VRAM being used by Xorg, the rest being used by webui. When I use 1.5x on 512x512 to 768x768, on fresh webui start, it works fine, but after some time, it gives me OOM error, as if VRAM leaks overtime. If after that I restart webui again, it works fine. When I use --medvram parameter, it shows same behavior, but with RAM. After some time of working, system begins to lag out, RAM overflows and kernel kills webui process with OOM error, just like with VRAM.
It seems that live generation preview takes additional memory - when i disabled it - i do not see memory problems on usual generations.
Seems new changes have some problems with memory - week old commit works fine, with last changes often runs out of memory even with lover settings. Before i used to resize: from 448x704 to 896x1408 (x2), but now even resize x1.3 - can run out of memory
Which commit works for you?
There is definitely something wrong with the memory management of stable-diffusion-webui. I have managed, a few times, to simultaneously upscale two 512x512 images to 1024x1024, simultaneously. However, it's inconsistent. Usually I could only upscale one before getting an 'out of memory' error from CUDA. Even then, I could upscale 1, 2, maybe 3 images (one-at-a-time) before the next one gets an out-of
memory error.
Adding --medvram largely resolved the issue for me, though occasionally I still get an out of memory error, though not very often.
Disabling live previews absolutely helps with the issue as well. Which makes no sense, because the live previews slow down the generation, so that implies that the image preview is happening sequentially and not in parallel with the generation, meaning live previews should not require additional VRAM.
I'm convinced that stable-diffusion-webui just doesn't manage the memory properly. I think the memory probably fragments all over the place, which is why sometimes the out-of-memory error from CUDA complains that it can't allocate free memory even though there is enough available, according to the same error message. But other times, there just isn't enough memory available, even though I've successfully completed more VRAM-intensive tasks like simultaneously upscaling two images.
The developers should look into resolving this fatal bug. It's demonstrably not an issue of insufficient VRAM; at least not for me. The program is (presumably) fragmenting the VRAM and also failing to release previously used VRAM. The CUDA_PYTORCH_CONFIG... options suggested somewhere in the wiki did not resolve the issue either.
Also, I've been running the program with literally nothing else on the computer using the graphics card. Not even a desktop environment. Just a frame buffer in Linux. Running nvidia-smi confirms that the GPU is not in use-- it was actually marked as powered off! So, nothing is fiddling with the VRAM except this program. Hence the conclusion that memory is not being managed correctly by this program. I think it is fragmenting the VRAM and failing to release memory.