[Bug]: Highres fix is zooming into content of cutting of heads etc.

[bbecausereasonss]

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What happened?

Euler A + DDIM (haven't tested others). Using High res fix at various resolutions above 512x. The picture looks good as it's being generated, then as soon as high res fix kicks in, it crops the image (even though it's not supposed to). This often cuts off heads. Was not happening before.

Steps to reproduce the problem

1. txt2image
2. DDIM/Eurlar A
3. High res Fix at .5
4. Watch the progress.

What should have happened?

Picture should not be getting cut off, cropped, punched in.

Commit where the problem happens

No response

What platforms do you use to access UI ?

Windows

What browsers do you use to access the UI ?

Mozilla Firefox, Google Chrome

Command Line Arguments

--xformers --deepdanbooru --no-half-vae --listen --port 7878

Additional information, context and logs

No response

[Buckzor]

This is how it's intended to behave. If you want it to stretch the first pass image then set your first phase resolution to 0,this will return the same behaviour as before where a 512x512 image is generated, then stretched to the size you want

[anastasiuspernat]

This is how it's intended to behave. If you want it to stretch the first pass image then set your first phase resolution to 0,this will return the same behaviour as before where a 512x512 image is generated, then stretched to the size you want

Can you please explain what do you mean by "set your first phase resolution to 0"? I set "Firstpass width" and "Firstpass height" to 0 and everything is still cut off in the latest commit. My target resolution is 768x1024.

[bbecausereasonss]

Yep, everything getting cut off. Was not before. Also, IMG2IMG inpaint + full res used to save a copy of the full res in paint square and is no longer doing that in the latest commit.

[freecoderwaifu]

Can confirm this happens only on non square resolutions. Manually setting Firstpass width and height to half of the target resolution fixes it, example: 1280x768 = Firstpass width: 640, Firstpass height: 384.

I think this is what setting Firstpass = 0 should do by default though, as it currently only seems to do that for square resolutions. Alternatively, a button or checkbox to auto set both Firstpass parameters to half the target resolution would be useful.

[freecoderwaifu]

Managed to fix it by changing line 636 in modules/processing.py from desired_pixel_count = 512 * 512 to desired_pixel_count = self.width /2 * self.height /2

Current code:

 if self.firstphase_width == 0 or self.firstphase_height == 0:
                desired_pixel_count = 512 * 512

New code:

   if self.firstphase_width == 0 or self.firstphase_height == 0:
                desired_pixel_count = self.width /2 * self.height /2

This defaults 0 to always be the half of the target resolution, thus prevents zooming and cropping on non square resolutions, while still allowing custom Firstpass parameters. High res fix still works as intended.

[freecoderwaifu]

Perfectly fixed by https://github.com/AUTOMATIC1111/stable-diffusion-webui/commit/ef27a18b6b7cb1a8eebdc9b2e88d25baf2c2414d, thank you again.