Inpaint function creates two pictures on next to the other

[boldsignal]

First bug report, sorry if it's bad.

When importing a picture in the inpaint function, both using drag and drop or from browsing files, the picture gets put twice in the preview where you're supposed to paint, one of the copies is put in the down right corner and it's the real copy. The function seems to be working as intended anyway.

Steps to reproduce:

Import a picture in the inpainting function

[Cyberes]

You ignored the bug report template.

[BassJMagan]

I'm having the same issue.

[BassJMagan]

You ignored the bug report template.

does there need to be a template if it happens 100% of the time? I have the same issue, screenshot above. it doubles up and one on left is all broken, one on right is where you inpaint, and if u try to x out it tries to immediately summon a drop image into it window again, etc, so it's registering clicks like twice or something too.

[Mozoloa]

I'll do it, this is kinda app breaking

Describe the bug Some images seem to break inpainting

To Reproduce Here's one of simplest way

1. Copy this image:
2. Paste it in the inpaint tab and see this

Expected behavior To just display it once in the center and properly align the masking tools

Desktop (please complete the following information):

• OS: W11
• Browser Brave
• Commit revision be1596ce30b1ead6998da0c62003003dcce5eb2c Clean Install

Additional context May I add that clicking the X button to remove the image brings up the browse file dialog, idk if this is a feature but as I only use copy paste this could be an issue

[BassJMagan]

i get it on chrome browser and like above post says, i also instantly get the browse file dialog on hitting X... though for copy/paste that's a non-issue since you could paste over it i think.

[Muskelmagier]

Also encountered the same problem, i am using Firefox

[bbecausereasonss]

Firefox - Occurs after first drag-drop of PNG into window. Chrome - Occurs on hitting 'x' then dragging dropping a different image into window' *Also get browse file dialogue on hitting x, where this was not happening before.

If I go straight to img2img window it works, but if I click "Send to inpaint" it does not work and simply says "Error"

[Mozoloa]

i get it on chrome browser and like above post says, i also instantly get the browse file dialog on hitting X... though for copy/paste that's a non-issue since you could paste over it i think.

you know what you're right and that's what I've been doing for so long, It's probably why I haven't noticed until today, where the glitch pushed me to try to remove the image

[Rabbitroo0001]

Confirmed. Illustrated here: https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/2875#discussion-4477775

[fortypercnt]

I narrowed this down to the move from gradio 3.4.1 to 3.5. Reverting 4ed99d599640bb86bc793aa3cbed31c6d0bd6957 and e8729dd0511f8410db967d9ef192645cfef1be8a fixes the issue.

[BassJMagan]

I narrowed this down to the move from gradio 3.4.1 to 3.5. Reverting 4ed99d5 and e8729dd fixes the issue.

is there a way to do just this while keeping current updates?

[Rabbitroo0001]

Gradio 3.5 is needed for iPads. But I've come to the same conclusion that the problems with the inpaint display is tied to the Gradio update by rolling back the distro to just before the Gradio update.

[Mozoloa]

Gradio 3.5 is needed for iPads. But I've come to the same conclusion that the problems with the inpaint display is tied to the Gradio update by rolling back the distro to just before the Gradio update.

Could you give us the hash ? Wondering if it's 7d6042b908c064774ee10961309d396eabdc6c4a

[fortypercnt]

I narrowed this down to the move from gradio 3.4.1 to 3.5. Reverting 4ed99d5 and e8729dd fixes the issue.

is there a way to do just this while keeping current updates?

I just manually put the version back to 3.4.1 in requirements.txt and requirements_versions.txt. You can use git stash to keep local changes while pulling new commits. I.e.

git stash
git pull
git stash pop

[fortypercnt]

Gradio 3.5 is needed for iPads. But I've come to the same conclusion that the problems with the inpaint display is tied to the Gradio update by rolling back the distro to just before the Gradio update.

Could you give us the hash ? Wondering if it's 7d6042b

Yes, that is the last commit before the gradio version bump that caused the inpaint display issue.

[NYKevin]

Some information in dupe bug #2795, but it's mostly just a rehash of what was discussed above. No need to read it unless you are looking for overly-specific information about my exact observations etc.

[krishammes]

Hey all, i just ran into this on an ultrawide, 25/02/23...

However I could replicate and found out what caused it. Its when you zoom your default chrome scaling (CTL-middle mouse) if its less than 100% (aka if its 90% for example) any image thats wider than it is tall bugs out.