BUG with resolution calculations

[dtxn]

Hi. 16:9 standard HD resolution is 1920x1080. So if divided by 2 then should be 960x540, but slider shows 960x536. Didn't check other ratios, but if this has issue, so probably other ratios also.

[thomasasfk]

Hey, I made a change recently to make sure all numbers are multiples of 8 - so that will be the root cause of this.

I actually think that's only required for image 2 image, so I'll look at changing it back to anything for text to image.

Thanks for raising though.

[thomasasfk]

Don't think this will be a massive change so I'll look at this tomorrow morning.

[dtxn]

Ok, thank you. Also I just found strange thing: if I unlock and try to fix resolution manually, I simply can't put on 540 with arrows- it's either 536, either 544. If I put manually 540, so then it shows what I put, but I don't feel comfortable with that, when arrows can't put, what I want :) Is it possible somewhere in settings to make, that I could rise by only 1 increment, not by 8 ? Of course this is auto1111 problem, but maybe it also makes, that your script doesn't show correct ratio ?

[thomasasfk]

Ok, thank you. Also I just found strange thing: if I unlock and try to fix resolution manually, I simply can't put on 540 with arrows- it's either 536, either 544. If I put manually 540, so then it shows what I put, but I don't feel comfortable with that, when arrows can't put, what I want :) Is it possible somewhere in settings to make, that I could rise by only 1 increment, not by 8 ? Of course this is auto1111 problem, but maybe it also makes, that your script doesn't show correct ratio ?

Hmm. I think it's by design that it's an increment of 8 as it will break image to image if it's not that. I'll take a look at it for text to image though and get back to you tomorrow!

[Aespaaa]

locking in text2img , makes both the sliders the exact same length, (version 1.3.0) WEBUI

[thomasasfk]

locking in text2img , makes both the sliders the exact same length, (version 1.3.0) WEBUI

Hi, this is expected behaviour - when we lock to the aspect ratio, we change the minimum and maximum length of the sliders, as to prevent potentially erroneous user input. The fact that they're the same length makes sense, since they we adjusted the minimum and maximum and we are matching the aspect ratio accordingly.

I do acknowledge this is not very intuitive, and without knowing what's happening it doesn't make much sense, but it was the easiest way I could find to allow users to change both the width/height instead of just whichever one was highest.

[dtxn]

With that is possible to live, but the main issue as I wrote in the first post: when I make lets say 16:9 aspect ratio 1920x1080, so then everything is ok. But when I slide to lets say to width 960, height suppose to be 540. But it's not, it fixes to 536 which is incorrect. And it renders also at 960x536.

[thomasasfk]

With that is possible to live, but the main issue as I wrote in the first post: when I make lets say 16:9 aspect ratio 1920x1080, so then everything is ok. But when I slide to lets say to width 960, height suppose to be 540. But it's not, it fixes to 536 which is incorrect. And it renders also at 960x536.

Yes sorry, I was replying to the other uses comment, I will look at this later today! Sorry a little busy at the moment with work. You can revert back to the old version if this is a pressing issue for you:

From the root of the a111 webui:

cd extensions/sd-webui-aspect-ratio-helper
git checkout c3193a5dbceebac85e1b4155ff96e9a127ad558a

Note this will put you in a detached head state at https://github.com/thomasasfk/sd-webui-aspect-ratio-helper/commit/c3193a5dbceebac85e1b4155ff96e9a127ad558a - after this has been changed you can go back to the newest version with:

cd extensions/sd-webui-aspect-ratio-helper
git checkout main

In theory that should work ^ but haven't tested it myself. Not sure if A111 checks out main or something when starting...

[dtxn]

Older version had the same problem: I just checked my older rendered images and it was the same wrong resolution 960x536. I also not sure if you can fix that with new version, as it seems, that Auto1111 by itself "walks" by 8 steps: 536 and next step is 544. But I'm not a programmer, so maybe I'm wrong and you will be able to fix :)

[thomasasfk]

Older version had the same problem: I just checked my older rendered images and it was the same wrong resolution 960x536. I also not sure if you can fix that with new version, as it seems, that Auto1111 by itself "walks" by 8 steps: 536 and next step is 544. But I'm not a programmer, so maybe I'm wrong and you will be able to fix :)

Ah maybe not then. I think there is a good reason for that though, something to do with how the models are trained relying on a multiple of 8... don't know though, would think it's there for a reason.

[dtxn]

But manually I can add 540 and it renders 540. So I don't think it's for a reason... I will ask in Auto1111 page about that.

[dtxn]

I got the answer "It is a common limitation that model output only supports specific scales, and WebUI only supports resolutions that are multiples of 8, and other dimensions will be rounded." So I'll try somehow to live with that.

[thomasasfk]

Thank you for finding that! Going to close this now if that's alright.