Fix for "Send To img2img" Type Buttons

[Googolplexed0]

Small tweak to prevent an error where sending an image to another tab via a "Send To" type button expects base64 encoded text and attempts to decode it, but fails because image may not be base64 encoded. This occurs because image_from_url_text() attempts a decode whether or not the filedata has the "data:image/png;base64," string in front, which I expect to be an identifier that the decoding is necessary. My fix performs the decoding if the base64 identifier is present, or skips it if unnecessary. While I was digging around, I also realized that clicking any "Send To" type button while no image was present in the above viewer would cause an error, since the if filedata.startswith("data:image/png;base64,") check would be performed on a None type which obviously has no .startswith(), so I added a small check if filedata == None: return None to circumvent this error. This change was made in light of the error being caused by the extension Image Browser as described in issue #69, which is where I first offered my fix.

Although "Send To" type buttons work outside of the Image Browser extension without this change, they are not negatively impacted by this change. I have done moderate testing (i.e. pushing all "Send To" type buttons in most/all tabs) on my client and have experienced no new errors or bugs as a result of these changes. I am unfamiliar with how the Web GUI encodes and sends its filedata between tabs, so please advise or correct me if some of my changes were made in error.

I also created a small .bat file to manually update the python venv pip module since there was a recent pip update, and decided to suggest adding it to the repo as well.

Deployed on:
OS: Windows 10 Pro
Browser: Brave (chromium based)
Graphics Card: NVIDIA RTX 2070 8 GB

[vladmandic]

also remotely related issue #6434 - using urlencoded image for "send to ..." is not the greatest option to start with as all PIL Image properties are lost during transfer. this fix is still valid, just noting general issue.

[AUTOMATIC1111]

Adding data:image/png;base64, is what gradio does, or at least did in previous versions, before it started just using links to files on disk. Sending without was never meant to work and never did.

The one thing I'd accept from this PR is the first line, because as I see it would prevent red ERROR messages if you do "send to" without an image.

vladmandic: i think metadata in those base64 dumps could work, if it's actually included in the file.

[Nacurutu]

Hi, @vladmandic may I ask, this base64 thing (sorry, im not good at coding or programming) could be related to this issue? #6388 (comment)

Related to the "send to" button and the --gradio-img2img-tool color-sketch argument?

[vladmandic]

Hi, @vladmandic may I ask, this base64 thing (sorry, im not good at coding or programming) could be related to this issue? #6388 (comment)

Related to the "send to" button and the --gradio-img2img-tool color-sketch argument?

possible, but honestly no idea - i'm not a gradio expert by any means.

[AlUlkesh]

I'm probably missing something... but if the problem is, that gradio now returns a link in the form of outputs\\txt2img-images\\13294-8021104202-... then wouldn't simply adding something like this solve the issue?

    if isinstance(filedata, str) and os.path.isfile(filedata):
        return Image.open(filedata)

[vladmandic]

I'm probably missing something... but if the problem is, that gradio now returns a link in the form of outputs\\txt2img-images\\13294-8021104202-... then wouldn't simply adding something like this solve the issue?

    if isinstance(filedata, str) and os.path.isfile(filedata):
        return Image.open(filedata)

i think thats on the right path...

[Googolplexed0]

I'm probably missing something... but if the problem is, that gradio now returns a link in the form of outputs\\txt2img-images\\13294-8021104202-... then wouldn't simply adding something like this solve the issue?

    if isinstance(filedata, str) and os.path.isfile(filedata):
        return Image.open(filedata)

i think thats on the right path...

I would tentatively agree, but I have zero knowledge of gradio or io.BytesIO. If base64 encoding is not present in newer versions of gradio links, keeping the base64 decoding would be in the best interest of backwards compatibility. I will try to play around with this change later today, but see no immediate reason why this solution wouldn’t work. Would be happy to update my pull request if AUTOMATIC1111 agrees with vladmandic on AIUIkesh’s suggestion.

[AUTOMATIC1111]

Like I wrote before, I'd only accept the first line (and replace == with is).

Using Image.open on something that was encoded with .encode('utf-8') makes no sene to me. There is no bug to fix in the web ui related to this.

The bat file is also definitely not making it in, if the user wants, he can upgrade pip however he likes.

[AlUlkesh]

I looked a bit into this from the extensions's side.

Automatic is right of course. The extension needs to send a gallery object, instead of a filename.

What's more, there already is a fix for this, just nobody has merged the commit on the extension's side.

[crazyilian]

I looked a bit into this from the extensions's side.

Automatic is right of course. The extension needs to send a gallery object, instead of a filename.

What's more, there already is a fix for this, just nobody has merged the commit on the extension's side.

In the extension repo pull request yfszzx/stable-diffusion-webui-images-browser#51 does not fix all errors related to this behavior, as mentioned by many users in issue yfszzx/stable-diffusion-webui-images-browser#69. But @Googolplexed06's suggestion works for all users.

[AUTOMATIC1111]

I installed image browser and it sends image filename to the function you're editing. It was never meant to work to like this, never did, and it won't. The image can be either a gradio image object represented by a dict, a data: uri or a base64 encoded image data. I'm closing this PR.