Upscaling broken for non-512x512 images

[divVerent]

Tested in the Vulkan and CPU backends at 10c6501.

r() {
	../build/bin/sd --model ../build/v2-1_768-nonema-pruned.safetensors -p 'blue house with green grass' -W "$1" -H "$2" --steps 5 --upscale-model "$3" -o "$4"
}

r 512 512 ../build/RealESRGAN_x4plus_anime_6B.pth 512-512-up.png
r 512 512 ''                                      512-512-noup.png

r 384 512 ../build/RealESRGAN_x4plus_anime_6B.pth 384-512-up.png
r 384 512 ''                                      384-512-noup.png

r 384 384 ../build/RealESRGAN_x4plus_anime_6B.pth 384-384-up.png
r 384 384 ''                                      384-384-noup.png

r 256 512 ../build/RealESRGAN_x4plus_anime_6B.pth 256-512-up.png
r 256 512 ''                                      256-512-noup.png

r 256 256 ../build/RealESRGAN_x4plus_anime_6B.pth 256-256-up.png
r 256 256 ''                                      256-256-noup.png

Obviously run with a too low number of steps - the problem doesn't change with that though. The point is to see the effect of the upscaler.

w	h	regular	upscaled	difference	verdict
512	512				OK
384	512				BAD (vertical stripe)
384	384				BAD (horizontal and vertical stripe)
256	512				BAD (vertical stripe)
256	256				BAD? (seems like a big stripe horiz and vert, but not 100% sure)

Is there a workaround to use the upscaler feature even for non-square outputs?

[stduhpf]

Yes, this issue should be fixed by #484

[divVerent]

Confirmed that #484 appears to help. Gonna use stablediffusion.cpp for a while with that fix, let's see if anything breaks or not.

[divVerent]

Yes, all five test cases (and my actual use case) pass with #484 applied.

Thank you!