[Issue]: Inpaint sketch resizing image on canvas without being prompted

[mark-wd]

Issue Description

Following from #860

Updated to the latest build and the problem persists.

Digging deeper, I've found that this behavior happens during the following workflow:

• Generate a 512wX768h image in txt2img, my batch count was 4.
• Choose one of the images and click the "->IMAGE" button below to send to img2img
• On the img2img tab, click the "Inpaint sketch" button below the canvas
• At this point, computer resource usage spikes way up. The resulting image on the canvas is actually resized to be way bigger
• Browser slows down massively and any further work is halted due to the size of the image. If it manages to be processed, it results in DecompressionBombError.

Behavior seen on Win11/Firefox

Version Platform Description

2023-05-11 hash: 0f2a03a5

[vladmandic]

i still cannot reproduce. can you open browser inspector window (F12) and select image element - what does it show for its actual canvas elements? example - you can see in HTML that all canvas elements have correct width=512 height=768

[crazygonuts]

This is also occuring for me - copying an image from the sketch tab to the img2img tab upscales the image by 1.5x

the size of the image in the html image container under the sketch tab is correct (unscaled)

the size of the image in the html image container under the img2img tab after copying is incorrect (scaled)

[mark-wd]

Now that you mention it, it's actually all screwed:

I am doing this on a monitor with a pretty huge resolution... maybe it's capturing that as a basis or something of the sort?

[vladmandic]

@mark-wd yeah, that's clearly messed up, no question is the issue real or not. i wish i could reproduce, no idea why i cant. two questions:

• can you reproduce on chrome as well?
• are you using windows resolution scaling?

[mark-wd]

New tests:

• In Chrome latest: same result
• 1080p monitor instead of 4K: same result

One important thing is that Inpaint itself works fine. Maybe this has to do with the specific way in which Inpaint Sketch is invoked?

Well, anyway, this is not super high priority... still good if you can add it to your backlog.

[vladmandic]

Yup, I'll keep it in the backlog...

[vladmandic]

can you check if the issue still exists?

[vladmandic]

any updates?

[raisindetre]

Just chiming in that I'm getting the same issue/effect in A1111 v1.6.0 on OSX ARM M2. Slightly different workflow (sending to img2img from PNG Info, disabling all extension settings, clicking on Inpaint Sketch. Massive slow down of browser, canvas minimally responsive and huge canvas image sizes reported in HTML.

I suspect this is related to screen resolution in some way. I'm running on a Macbook Pro with a Retina dislplay, so 3024 x 1964 at 254 pixels per inch with I think some sort of display scaling.

[raisindetre]

Just chiming in that I'm getting the same issue/effect....

This was in latest Firefox and Chrome BTW. I tried changing display resolution to 960x600 and restarting A1111 but this time the image disappeared in the Inpainting Sketch canvas and got an unhappy face icon.

[raisindetre]

I have retested, this time setting Firefox application zoom scale to 50% and Inpaint Sketch works without fault so this seems to be the workaround at present until the code can address high-res displays as the img2img Inpaint canvas presently seems to do alright.

[vladmandic]

Thanks for the update...

[AlexeyWP]

Had about the same issue. It was caused display settings: initially was 125%. Returned it back to 100%. Now it works OK.

[alastaira]

Can confirm I just experienced the same issue.

• Clicking the "Send to Inpaint Sketch" button to send a 512x512px image from img2img makes browser (Firefox 118.0.1) very unresponsive, and subsequent attempts to use inpaint sketch crash out with a DecompressionBombError.
• On inspecting the HTML, the canvas elements have been created at 718x8092px (the mask is created at 718x4096px)
• Send to inpaint (not inpaint sketch) works as expected
• Windows Display had been set to 200%. Changing this to 100% appears to fix the problem (although makes my PC otherwise unusable!)

[vladmandic]

linking to actual upstream issue https://github.com/gradio-app/gradio/issues/5858

[vladmandic]

somewhat disappointing response from gradio team: https://github.com/gradio-app/gradio/issues/5858#issuecomment-1755422024 if you want to add to issue, please comment to gradio directly.

[vladmandic]

work on new canvas has started and all related issues will be tracked in #4358