What just changed?! Resulting images with same prompt and seed are now terrible.

[GalaxyTimeMachine]

Just updated to commit 4dbde22 and not getting good results. Exactly the same prompts, settings and seed are not giving the same as before, and I'm getting a lot of body horrors.

Edit: I think it may be related to the hires fix. I'm making 1024x768 images and hires fix used to get rid of body distortions...it's not any more. No distortions with lower res images.

[OoAnikioO]

yes, I have horrible results too, double / triple head, etc...
I also have a lot of memory cuda errors
could someone please tell me how to fix it

thanks

[ice051128]

Hi res fix is downgraded, that's why
ef27a18

[ghost]

just type "git pull" to your webui-user.bat

[GalaxyTimeMachine]

No, type "git checkout master", then "git pull" and run it.

[ghost]

oh, sorry, yes that

[ethanfel]

just git checkout COMMIT. There's no need to DL a zip.

here :
git checkout e672cfb
Going back to master
git checkout master

[manzomium]

thanks!

thanks @MikkoCastell but I'm still too ignorant to understand what I need to do, from where I can launch the cmd, when I need to do it, etc. I'll try to learn asap but if in the meantime you can point me to some resource or just try to explain I'd be so very grateful 👍 I understand this knowledge is quite important to have :-)

Here's what I did and it worked.. Go here (or any other commit version you prefer) https://github.com/AUTOMATIC1111/stable-diffusion-webui/tree/e672cfb07418a1a3130d3bf21c14a0d3819f81fb Then go to "Code" and download zip, open the folder and copy and replace all the files to the master folder... Be sure to keep any files you don't want overwritten like styles.csv, webuser.bat, webui.bat etc. or else you will have to input everything again

thanks a lot!! before doing that, I'll try the webui-user.bat solution.
to input anything on the webui-user.bat, I need Pyton. Will download and see 👍

[mile6919]

I can confirm this. Results are now bad, ugly images. If I use exactly same prompt, seed and model which gave me beautiful photos. Now I get ugly images, double bodies, double heads etc.

[ghost]

I have tested every upscaler and every width and height and still results are quite bad, older was much better :/

[fractal-fumbler]

try different upscalers :)

[manzomium]

Which one do you suggest? Latent is giving bad results. Thanks @fractal-fumbler !

[ghost]

These all are horrible in my opinion, results are simply bad compared to older version

[wolthorp]

lol

[fractal-fumbler]

Which one do you suggest? Latent is giving bad results. Thanks @fractal-fumbler !

give it a try :)
@Veraxus reported that even with upscaler "None" he is getting decent results
#6219 (comment)

[EdHerdman]

The new Highres. Fix mode is actually pretty simple. Previously, width * height represented the final canvas size, and we've been working backwards. Using Highres. fix properly meant doing math if you wanted to preserve the aspect ratio. It was very easy to select nonsensical settings like e.g. a final canvas width of 512 with an initial generation width of larger than 512, or just selecting Highres. Fix when you had a canvas size of 512x512 on a 512x512 model.

"Upscale by." just does what it says: It multiplies your initial width * height settings by the specified multiplier. That's why the new mode seems strangely slow - you're probably selecting a high width * height and then scaling more on top of that. You'll have to play with the denoising attribute to get results you want. Latent scaling was the old default and now you have the ability to go directly to the other scaler modes without doing img2img, which is also neat.

So the new Highres. Fix actually does what I wanted it to, but all the changes made it initially hard to understand what's going on. Giving independent scaling for x and y axes would be welcome for the rare cases people want that.

[auraria]

I no longer get the same image but my images are still very good. I just set the size I want (usually 960x960) and I have hires fix turned off and the images look great. No double heads or anything.

yeah because you're genning at a static 1:1 small resolution. Try genning anything outside of that, like 16:9 for example lmfao.
This update completely broke non-1:1 high-res genning where 85% of the results are trash

[Clivey1234]

Hires fix is definitely broken, getting the same as people above. I've rolled back to e672cfb

Everything has been fine up this this git pull today. On my 3080 generating a 1280x720 simple prompts occasionally gives cuda memory errors, which shouldn't be happening on a 12gb gpu, never had them before. When I can generated a 1280x720 image, it has all the signs of the Hires fix not working on this build

[moon91210]

This is true but previously we were able to set the target resolution, now we cant do that anymore.

[fractal-fumbler]

This is true but previously we were able to set the target resolution, now we cant do that anymore.

roll back to previous hires fix or make a pull request, which allow to make target resolution

[tusharbhutt]

The new Highres. Fix mode is actually pretty simple. Previously, width * height represented the final canvas size, and we've been working backwards. Using Highres. fix properly meant doing math if you wanted to preserve the aspect ratio. It was very easy to select nonsensical settings like e.g. a final canvas width of 512 with an initial generation width of larger than 512, or just selecting Highres. Fix when you had a canvas size of 512x512 on a 512x512 model.

"Upscale by." just does what it says: It multiplies your initial width * height settings by the specified multiplier. That's why the new mode seems strangely slow - you're probably selecting a high width * height and then scaling more on top of that. You'll have to play with the denoising attribute to get results you want. Latent scaling was the old default and now you have the ability to go directly to the other scaler modes without doing img2img, which is also neat.

So the new Highres. Fix actually does what I wanted it to, but all the changes made it initially hard to understand what's going on. Giving independent scaling for x and y axes would be welcome for the rare cases people want that.

Was this change documented in detail anywhere? It's hard to understand without context. excuse my ignorance, but please let me know if I have this correct:

Under the old model, I could make an image of, say 1025x1536 and just click Highres fix and select the default. I made mine default to 768x768 for SD2.1 checkpoints. In my head, this means an initial 768x768 image was created and then upscaled to 1024x1536. Is that right?

For the new model, if I want a 1024x1536 image, do I set the the HxW to 512x768 and the highres upscale to "x2"? I tried this and the output image is indeed 1024x1536 but the info text is incorrect:

Seems to work, will have to test more

[freecoderwaifu]

Before: if any of the firstpass sliders = 0, the image was always generated at 512x512 then resized to the resolution set on the regular width and height sliders, which caused the image to get cropped if it tried to fit non square ratios

Old example with 1280x768:
Target res: 1280x768
Firstpass width = 0
First pass height = 0
Image gets generated at 512x512 then upscaled to target res
Final res: 1280x768, very noticeable cropping

Alternatively, need to use an external calculator to calculate better firstpass values, https://preyx.github.io/sd-scale-calc/
Firstpass width= 704
Firstpass height= 448
Final res: 1280x768, less cropping but still some cropping.

To prevent cropping, set firstpass to half the target res, which can cause images to get generated even further below 512 and is less optimal
Firstpass width= 640
Firstpass height=384
Final res: 1280x768, no cropping.

tl;dr it was a hassle

Now: the image gets generated at the resolution set by the regular width and height sliders, then multiplied by the Upscale by slider = final resolution

One new example with 1280x768:
Target res: 854x512
Upscale by Multiplier = 1.5
Final res: 1280x768, no cropping

Basically the regular width and height are now what the old firstpass sliders were. It's much simpler.

However, yes, this does mean it "negates" some of the original point of high res fix to prevent double bodies and weird generations with resolutions higher than 512x512, and is now more of an upscaler, but the fix is simple by setting your res to 512x512 then adjusting the Upscale by slider, or sticking closer to 512 for non square ratios. The benefit of this is that there's more freedom of experimenting with different resolutions and ratios, or at least the same freedom that the old firstpass sliders provided really, with the added benefit of the multiplier.

If you don't have Show image creation progress every N sampling steps or Save a copy of image before applying highres fix enabled. you might not have even been aware that your image was actually being cropped at non square resolutions.

If you didn't mind or liked the cropping on non square ratios, you could set your res to 512x512, Upscale by 2 or a bit above 2.1 depending on your VRAM, then use img2img to resize that, or manually crop and resize it externally. It is more of a hassle, but you'll at least get more controlled cropping than the old method did.

If you only do 1024x1024 images or square ratios then you only need to set your res to 512x512 and Upscale by 2 or above depending.

tl;dr the old firstpass sliders are now the regular width and height sliders.

The one thing that would be cool, is if the Upscale by slider showed the actual final resolution below it, just to make it more clear.

I'm nowhere near a real coder, but this is how the old code looked like when I made #5382. It shows that firstpass = 0 was hardcoded to generate 512x512 images and then scaled those.

if self.firstphase_width == 0 or self.firstphase_height == 0:
                desired_pixel_count = 512 * 512
                actual_pixel_count = self.width * self.height
                scale = math.sqrt(desired_pixel_count / actual_pixel_count)
                self.firstphase_width = math.ceil(scale * self.width / 64) * 64

[freecoderwaifu]

Since most models were and still are trained at 512x512, anything above it can cause the samplers to get confused, which can create double bodies and other abnormalities.

It doesn't entirely negate the fix since double bodies don't always appear above 512x512 and not in every model, though the further you get away from 512 the more chances of weird details or doubles. The original fix was to hardcode everything getting generated at 512x512 then scale that, since it guarantees to stay within the original training res. However with 768x768 starting to slowly become more common, it means that the old method with firstpass = 0 was still generating at 512x512 even for 768 models.

As better models get released and VRAM optimizations are added, a fix will technically no longer be needed, or rather it might need to constantly get hard capped at whatever the new limit is, but also keep in mind the older limits for older models. The new method makes it easier to adjust the firstpass by basically merging it to the regular height and width sliders, and more importantly (at least to me and I agree it's not the same for everyone) is it prevents the random cropping that happened before.

[tusharbhutt]

Thanks for the detailed response! Now I just have to figure out how to get it working properly, or if it's even possible, with a non-square image if I want to recreate it and the highres itself was square.

I have an image that is 768x1152, and the HR was set to 512x512. Trying an HR of 384x576 and scale of 2 does not work, nor does 512x576 with scale of 2. Using 512x512 and scale of 2.25 gives me a 1152x1152that is 90% accurate at replicating the original 768x1152 image but still "off" or so it seems because now facial features are wider in this one example I am playing with. This will be fun as the scaling cannot be set independently :)

[fractal-fumbler]

Old example with 1280x768: Target res: 1280x768 Firstpass width = 0 First pass height = 0 Image gets generated at 512x512 then upscaled to target res Final res: 1280x768, very noticeable cropping

point is that for non-square resolution first pass resoluton wasnt 512x512.
it was something like 592x448px for image that needed to be upscaled to 1024x768

[Dasor92]

i tested the new feature very heavily and i can assure that is nowhere near the old one. The noise reduction slider is pretty much pointless now if you set it to values lower then 0,5, with the old settings if you set the denoise to 0.1 the image looked clean and sharp just very similar to the one generated first. If you set the value to 0.9 the first image generated would have been the same, but the "fixed" one would have looked very different. with the new settings if you set the highres fix to 0.1 it generates a very blurry image that is useless and worse than the first generated image. Also, it doesn't do lesser steps as it used to be, with 30 steps it should do 33 steps total, but it does 60 steps, regardless of the option in the settings.

[MV799]

However with 768x768 starting to slowly become more common, it means that the old method with firstpass = 0 was still generating at 512x512 even for 768 models.

The HR fix was really just a badly hardcoded fix, which was fine months ago, but now it made no sense.

[mile6919]

With latest commit:
8149078
Everything works better now. Hires fix works again better and there is more possibilities to adjust output resolution and upscaling

[Dasor92]

Yup, just tested, the denoising strength now works, but the denoising steps are very random, the slider works 1 out of five times

[user2734283]

I would like to just use the old highres fix without reverting to an older version. My extensions update themselves and some included the mess of a fix in it and I cannot replicate my old good results. Now reverting to an older version isnt even an option anymore because the extensions just went with the chaos and integrated it, resulting in very poor performance and quality

[freecoderwaifu]

Changes are great, now you can auto resize and crop from the highres fix option if you want to.

I would like to just use the old highres fix without reverting to an older version. My extensions update themselves and some included the mess of a fix in it and I cannot replicate my old good results. Now reverting to an older version isnt even an option anymore because the extensions just went with the chaos and integrated it, resulting in very poor performance and quality

What you could do reproduce the old behavior:

1. Set your res to 512x512, set Upscale by 1, then resize to your target res using the Resize to sliders.

2. Use the old calculator and set your res to that, then Upscale by 1.7-1.8x (or rather take your target res and divide it by what the calculator gives you for the first pass, and that should give you a close enough Upscale by ratio) or just Resize to your target.

https://preyx.github.io/sd-scale-calc/

3. Set half of the res you want as the normal res, then Upscale by 2 or just also Resize to your target.

That should pretty much reproduce the old behavior, if you want to generate new images using the old method anyway. The UI already auto imports values from older generations and auto converts them properly.

[tusharbhutt]

With latest commit: 8149078 Everything works better now. Hires fix works again better and there is more possibilities to adjust output resolution and upscaling

Are these new features documented anywhere? The commit has no real useful notes. i see there are now about ten options to upscale, but without knowing that they do, it's gonna be a crapshoot

[bbecausereasonss]

What does "high res steps do" is there an explanation of this new method?

[tusharbhutt]

What does "high res steps do" is there an explanation of this new method?

From what I can tell, and i am not sure, but it appears you can run the images at the resolution you set, so let's say 512512 for 20 steps, and then run the upscaler independently, so at 2X for only 10 steps if you want... or 30. Leaving it at zero will run it the same number of steps as your initial image.

[topboysyp]

After today's upgrade the AI was generating different pics even though I'm using same prompts, model and seed, same everying. Infact I'm using PNG Info to analyze pics then sent to txt2img but it still generate different pics.

e672cfb
This branch still generating different pics from the old one. I guess I was using a even older branch than the e672cfb.

Was there any older branch like one week earlier available?

[Drakmour]

SAME! It's killing me! Every generation on same settings gives different details! :-(

[bbecausereasonss]

KINDA FIGURED IT OUT.

Basically you have to set your starting width/height to something that the model was trained on ie 1.5 model (512/512) you don't want to go far beyond that aspect.

Then you set your high-res fix width/height to what you want the final result to be.

If you're using latent option then set your steps to around .5-.7 (anything less or more) seems to produce either very blurry images or double heads etc.

Now it seems to work...

Although I'm not sure why they re-wrote it this way, b/c this seems just MORE work.

[freecoderwaifu]

You're just being exposed to settings that were always there in the Settings page and now are in the front or were hardcoded and had no way of changing them without directly editing the code, you might have been using the defaults all along. Latent upscale was the old Upscale using latent in settings, it already needed high denoise above 0.5 to prevent blurry images. I also explained how the old method used 512x512 as a base in a post a bit above and how to reproduce the old method for new images if you really wanted to. Basically options were just reordered better and the old functionality is all there.

[bbecausereasonss]

Okay, so beyond the settings I posted why on earth would you want to mess with them to create blurry and or garbled images?

[freecoderwaifu]

The benefit of Latent upscaling is sort of "brute forcing" more detail into a generation, but it does need higher denoise above 0.5, that's the way it always worked when it was sort of hidden in the Settings page. A really nice thing is now the upscalers are right there in the high res fix menu without needing to change them in Settings, you can download a variety of them and try them out by extracting them in models/ESRGAN each in their own folder.

https://upscale.wiki/wiki/Model_Database

There's far more freedom and far more control now with high res fix, just need to be familiarized and experiment with the settings beyond the defaults. You're no longer limited to everything just being generated at 512x512 then scaled and randomly cropped in case of non square ratios. Everything being hardcoded to be generated at 512x512 was especially bad for 768 models, now you can easily pick your base res and resize from that either with Upscale by or the Resize to sliders.

I think the misunderstanding comes from maybe not fully knowing what a firstpass is, from the old sliders. A firstpass is simply an image generated without the high res fix option enabled. When you enable highres fix, it generates an image normally, then that image gets put through img2img at a higher res, which is a secondpass, and gives the final image. Now you can also specify the steps for that secondpass, lower steps than the firstpass for faster secondpass processing but lower detail, higher steps than the firstpass for more details but slower secondpass processing. Before, the secondpass always only used half the steps of the firstpass IIRC.

[bbecausereasonss]

Helpful reply, thanks for clearing this up!

[Alphyn-gunner]

Ok, after some more tinkering and experiments, I think, in general, the new new Highres fix, that has the "Resize to" sliders is actually superior, but it needs a lot more manual work from the user to the point of being impractical for most scenarios. I don't think it's possible that new users will figure out how to use it properly, and an automatic mode that sets the original resolution for the user or emulates the old "one checkbox wonder" behavior would be cool.

Here's how you use the new Hirgres. Fix:

1. Set your desired resolution in the "Resize to" fields.
2. Set the highres steps to non-zero, 20 is a good starting point. You can try changing other values, but they're mostly ok as it is. If you know what they are, you know what to do. If you don't know, you don't have to touch anything. IMO, the upscaler doesn't really matter unless your denoising strength is really low, so you can set it to nearest or lanczos to save a second or two on upscaling.
3. Figure original width and height values that are close to the size of your model picture size (i.e. it should have roughly the same number of pixels), don't give you the repeating patterns and have the same-ish aspect ratio as your desired resolution. So for example if you want a 512 by 1024 image, try setting Width and Height to 384 by 768 for a 512-size model. If your "resize to" aspect ratio does not match the original aspect ratio, your image will be cropped after resizing, I wish there were an option to scale it, breaking the aspect ratio, like we have in img2img. You will probably have to do some math to figure out the right size. You can use an external tool, like others have already suggested: https://preyx.github.io/sd-scale-calc/. You can also just leave the Width and Height at default, 512x512 or 768x768, but keep in mind that your picture will be cropped, which may not work on a lot of subject matter.

Using these settings I get decent results most of the time, sometimes better, sometimes worse.

The worst thing about this new Highres fix. is that from the UX perspective it's just a mix of parts pulled from the extras and img2img tabs that is impossible to figure out without a guide.

More or less advanced users were always able to do exactly all of this using the Extras tab and ing2img. Generate - resize - refine in img2img. Less experienced users will click the Highres fix checkbox, see that it doesn't do anything with the default settings, see a lot of settings and nope out. Some will figure out that they have to set the steps to a non-zero value and will see that now it takes several times as long to generate an image and the result is still bad and then nope out.

In my opinion, the txt2img tab is not the best place for all of this as it just duplicates the functionality present somewhere else in the ui. As I mentioned in the opening paragraph, a one button solution that figures out the settings for the user that work most of the time would suffice. If you want it to work with models of different picture sizes, just make a single field for entering the model base size and let the computer do the rest of the math.

[user2734283]

I talked to the creators of openOutpaint and they implemented a fallback solution for everyone reverting to an older version because of this new implementation. I tested it and openOutpaint works as expected again with an older version of this repo. They responded quickly to this issue and are really professional about it. Premium extension right there.

edit: Clarification: everyone on an older version can just ignore the new settings and it will work like before

[ghost]

If anyone's wondering what's been working for me is this:
First Pass (the initial image settings) should be set to the standard for your model, either 512x512 or 768x768.
Then click the high res button, and set the width and height to whatever you want the end result to be. For me it is 1080x1920.
I am not sure if setting the scale multiplier to 1 or 2 does in this context, Ive just left it at its default 2.
I set high res steps to 20, but I think you can do more for the same effect on the end result that higher steps would do on the original.

If I set my original image higher than the standard for the model, like, 512x1080 etc, it seems to always fail. I heard in a forum that setting below the standard works fine, if you want better aspect ratio handling, i.e. 384x512, etc.

[YukiSakuma]

I can't seem to reproduce my non hires fix generations too, I double checked my prompt, seeds, hash model, samplers, steps, clip skip, ensd but the newer output is different from the old one.

[Centurion-Rome]

Wanted to give new hires try but no matter what prompt + negative prompt I get often screwed images (doubled body parts)
examples: 768x576 new Hires x2 Latent upscaler:

Bring old Hires.Fix back - it was working!

[Drakmour]

Use 0.5 denoise and less. It helped me. I used to put 0.7-0.9 before and it worked fine, now it is ok only on low denoise. There are also couple upscalers that were buggy as I remember from my tests. Maybe it were latent and second latent.

[bbecausereasonss]

I also don't fully grasp the new settings or the point when so many times I'm getting double yes, mouth's noses, weird shit that actually never used to occur before.

[chewtoys]

OLD VERSION

• https://github.com/AUTOMATIC1111/stable-diffusion-webui/tree/fd4461d
• fd4461d
  If that is what you want, how it used to work.
• do not git pull on this version
• download the zip extract it and run webui

OR

git checkout fd4461d

TO RETURN TO NORMAL VERSION
git checkout master

• This is before all the fuck ups happen.

[Drakmour]

I tried to turn off and on the "old karras" setting but it still didn't help. All other settings I guess are irrelevant cuz I get different results even without hires fix on 512x512 simple generation. I also don't use "extra" square near seed. I do indeed use xformers but I don't think it should be that way with it, cuz I used it before updates and it worked just fine. I think that there are some new settings or new values that changed during the update. Any more guesses what can cause it?

[Drakmour]

And about VRAM, I get it all the time, even on same settings. One time it works, another time it shows error. Very unstable. And it also runs 2 progress bars before the error, and runs out of memory on third procedure. So much time wasted every time for first two passes.

[chewtoys]

And about VRAM, I get it all the time, even on same settings. One time it works, another time it shows error. Very unstable. And it also runs 2 progress bars before the error, and runs out of memory on third procedure. So much time wasted every time for first two passes.

yeah this is why i went back to older version, its just not worth the time investment to work around it, just too many things are broken.

[Centurion-Rome]

yeah this is why i went back to older version, its just not worth the time investment to work around it, just too many things are broken.

That's the point! +1

[PleezDeez]

And about VRAM, I get it all the time, even on same settings. One time it works, another time it shows error. Very unstable. And it also runs 2 progress bars before the error, and runs out of memory on third procedure. So much time wasted every time for first two passes.

I've noticed this as well after using the upscaler in extras. Ooms a lot more frequently til the server is restarted

[Centurion-Rome]

To bring old Hires.Fix and move "new buggy" as extension script pls vote/comment for:
#6725

[PleezDeez]

Go in settings, compatibility, and make sure the 1 about hires fix is checked

[Centurion-Rome]

Go in settings, compatibility, and make sure the 1 about hires fix is checked

It is now the same as "old Hires.Fix" because it uses "...set final resolution..." and old HiRes.Fix was working in other way (initial resolution) so still is not the same algorithm as it was where you have set initial resolution which was later used to denoise to new one.

[PleezDeez]

Also make sure if you're using high res fix to not use the Latant upscaler or really any of the others besides the 2 R-ESRGAN 1s are garbage but default is latant.

[Drakmour]

I like LDSR more. It's more VRAM eating one, but gives cool result with great background.

[Alphyn-gunner]

Sounds like a placebo effect, honestly. Does the upscaler even matter at all if the image goes through additional diffusion after the upscaling? Using the DSLR upscaler, which is hella slow definitely sounds like a waste of time in this particular scenario. Unless you're setting your denoise strength or higres steps to 0 a.k.a not using the actual highres fix.

[Drakmour]

I made generation with all the upscalers and I liked LDSR the most. And yes it is a bit slower and more VRAM eating than others.

[PleezDeez]

I'll check it out later. I think that was one of the others I didn't mind as much. Lanzcos and latent are just bad tho lol