stable-diffusion-webui
stable-diffusion-webui copied to clipboard
AUTOMATIC1111
[Feature Request]: Return highres fix specific resolution.
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 ?
Would it be possible to add an option to return the resolution upscaling feature for highres.fix like it used to be? Currently it only allows you to upscale by a specific amount of passes.
I used to render an image in 320x320 then upscale it to 768x1280 or something like that, the new change doesn't allow this workflow anymore.
Thanks!
Proposed workflow
Add an option in the settings tab to return the old Highres.fix UI/method.
Additional information
No response
Width * height are doing the job that the Hires. fix "firstpass" options used to. You set the dimensions of that first pass with height and width. The "upscale by" slider multiplies both dimensions by the selected ratio for the upscale - if you have a 512x512 first pass, selecting 2x will output a 1024x1024 image. Unless you're using some kind of fancy script, there should only be two passes - the initial composition at the first pass resolution, and then the pass to scale the content. That's not changed.
It's actually simpler this way because it's easier to get the correct aspect ratio and stops people from rendering a bunch of stuff that gets cropped from the final canvas, like selecting an old firstpass setting of 1024 for a canvas dimension of only 512.
Width * height are doing the job that the Hires. fix "firstpass" options used to. You set the dimensions of that first pass with height and width. The "upscale by" slider multiplies both dimensions by the selected ratio for the upscale - if you have a 512x512 first pass, selecting 2x will output a 1024x1024 image. Unless you're using some kind of fancy script, there should only be two passes - the initial composition at the first pass resolution, and then the pass to scale the content. That's not changed.
It's actually simpler this way because it's easier to get the correct aspect ratio and stops people from rendering a bunch of stuff that gets cropped from the final canvas, like selecting an old firstpass setting of 1024 for a canvas dimension of only 512.
Thanks for the reply! I only thought the old way of doing it allowed more freedom in recreating old prompts (or seeds) that had specific settings that can no longer be replicated, I think it should be added as an option just to offer a little bit more freedom. Just my thoughts, it's not the end of the world if it stays this way, it's not counter intuitive.
Recreating old seeds should be simple - just take the first pass values and plug those directly into height & width. That said, the scaling steps have changed in some ways but I don't see anything inherently wrong with the new setup that makes it impossible to match up with the old stuff.
Maybe reading PNG Info will be automated. I don't think WebUI records a field of its own version into PNG Info, but the "firstpass" keyword would be the clue they need to pass those values into the new UI setup.
Final thoughts: I would rethink running modern Stable Diffusion models at less than 512 pixels on a side in the first pass. If you are using a standard checkpoint like stable diffusion 1.5 or whatever, it's trained on 512x512 (768 pixels in some newer models). These models are meant to be run at 512 (or 768) pixels. If you run it at a lower resolution, the results are blurrier, less detailed, and may be weirdly cropped. There's no advantage to doing this as a practice because it makes it much harder to understand what the model is doing - you're only seeing part of the image. If you need to crop later it's easy enough to do that afterwards.
I hope that I am not just dense, but...
Recreating old seeds should be simple - just take the first pass values and plug those directly into height & width. That said, the scaling steps have changed in some ways but I don't see anything inherently wrong with the new setup that makes it impossible to match up with the old stuff.
I have images that have settings of,
Size: 2048x1408, Seed resize from: 1024x704, First pass size: 768x512 using ESRGAN 4x
When I import the complete prompt and settings into the version of Automatic1111 with the updated hires method, it loses a quality of the previous ESRGAN 4x that I liked very much. I tried all of the variations of upscalers that work for me, and I couldn't get the level of pleasing "grain" and detail.
Additionally, I like to play around with the first pass Height and Width to get additional variations you can't get by say Sigma churn or whatever other methods are available, unless I'm mistaken on that.
I do agree that this new method is more intuitive, but having it as an option to use the old method would be very good for me, and I think at least a few others would agree.
Please enlighten me on being able to have my cake and eat it too by having the old way and looks while still being able to get updates. TIA.
edit: While I wasn't able to get the exact look as before, I ran the latest UI on one of my other computers and was able to get a pleasing, though not exactly the same look as I had before. So, it is just quite possible that some other slight difference in my installation is preventing me from getting the exact look I was getting before. It's close enough, and considering the pace of everything moving there is no point in trying to hold on to something old that no doubt will be unacceptable quality possibly even a week from now, let alone in a few months or a couple of years.
I got so many issues with this new highres fix version. Since now there is not only a highres fix, but you can also apply an upscaler, now, if you do not use any, the image generates duplicate bodies and errors... and if you do, the images are generated with rendering issues, blurry, with lack of detail or low quality overall... (not like 1 week ago). Before this update.
Last week I was able to generate images over 960 x 1280 px with the highres fix option activated and it gave me fantastic and detailed results, clean colors, well-achieved lines, sharp full-body images, detailed eyes. I would love to have this option to "use the highres fix" from before this update
If you are seeing duplicates you almost certainly have the wrong settings. In the old UI style, width * height was the final canvas size, and the initial composition was based on the hires. fix-set width * height.
In the current UI, you set the width * height of the first generation directly. For 512x512 models, the sensible values are normally 512 to 1024 (or more likely 768).
If you load up your old output images in the PNG Info tab, you may be able to see the first pass width and height, and Send to txt2img will set up WebUI with the right values. If it shows "first pass size: 0x0" you'll probably have to guess, unfortunately.
Recreating old seeds should be simple - just take the first pass values and plug those directly into height & width. That said, the scaling steps have changed in some ways but I don't see anything inherently wrong with the new setup that makes it impossible to match up with the old stuff.
I have been unable to prove this out. I have been saving pre-highres fix images and have all the values I should need to replicate, but this does not seem to work as expected.
Providing a reverse-compatibility flag would be a good quality of life for those wanting to replicate the old processes.
Recreating old seeds should be simple - just take the first pass values and plug those directly into height & width
How do we determine what the old firstpass values were? By default the metadata always reported 0x0.
If you have a square aspect ratio start with the model's default, 512x512. If that doesn't work, try increasing one value to match the aspect ratio - that may take some math, but getting precise aspect ratios also required math in the old method, so we're just paying the piper now for that automatic setting. Really do wish they had recorded that setting properly before this change :/
I would also love an option to revert this new multiplier based method, it seems convoluted and far more difficult to work with. Logically you expect the main width and height sliders to represent the final output, and previously it didn't take any math to get the desired resolution, just consideration of the first pass possibly being cropped.
When I wanted to figure out the correct aspect ratio for a canvas with the old style, I'd have to take my first pass dimensions - like 768 / 512 - and then multiply the result by my new dimension I wanted, or some such, avoiding multipliers less than 512. The new highres fix upscale slider? Just take your first pass dimension and multiply it by the slider to see if it matches, no division required.
It's important for Stable Diffusion to allow you to work from the first pass resolutions because that determines your composition. Otherwise, you can easily have a weird aspect ratio or cropped content which wastes your GPU time.
I think the main complaint would be solved by putting a label on the upscaler to show what the final canvas dimensions will be - and having two upscale sliders when you want different aspect ratios would be fine too.
It looks like it may be impossible to recreate some old results.
On a 512x768 image whose metadata reported 0x0 as the first pass resolution, feeding it into the PNG info tab set the txt2img resolution as 448x640 with an upscale multiplier of ~1.143 (i.e. 512/448). Note that this gives a non-integer for the other dimension. In the actual output it came out as 728, which is not the 768 of the original image. The composition was similar but the image itself was still different. 448x664, using an odd resolution to approximate the correct aspect ratio, gave a 512x752 image that is also a similar composition to the original, but more different than the 448x640 one was. 512x768 and a multiplier of 1 gave a different composition entirely.
Whatever the merits of the new version or flaws of the old version may be, I don't like having lost the ability to replicate a huge fraction of what I and others have generated in the past.
Check out this comment about it. I was pretty close to the right track, looks like, but this has some more details: https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/6217#discussioncomment-4587206
As i said also in the other thread, 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. sure, there are many new capabilities but the denoising strenght is bugged as it is right now, and should be fixed, or reverted.
I wanted to add that I got better accuracy in reproducing generations made with the old implementation of hires by changing this option in settings/compatibility
"Use old karras scheduler sigmas (0.1 to 10)."
The first one is the original image and the other two show the difference with that option off and on
I like the rework but I don't like how I'm not getting the same results for latent space anymore, they're slightly off and it isn't because of xformers.
The old style of hires fix was implemented in d4fd2418efb0986a8226add0b800fb5c73ffb58c and is very appreciated, but it's missing one key thing: first pass resolution. Without it, it tries to aim for an appropriate ratio as close to 512px as possible, but this is not ideal for 768 or higher models. Bringing that back, plus moving the crop operation to pre-upscale instead of post in both the new and old versions, would be feature parity with the hires fix before rework, and everyone will be happy. :)
Rerouting this issue to #6269 . This one was created earlier, but the name on the other one makes more sense, plus old input style is back, but underlying process is a bit different, and it's core of the #6269 .
