[Bug]: Adetailer error during inpaint upscale (RuntimeError: Inference tensors do not track version counter)

Vinzero-SS commented 2 months ago

Checklist

[ ] The issue exists after disabling all extensions
[ ] The issue exists on a clean installation of webui
[X] The issue is caused by an extension, but I believe it is caused by a bug in the webui
[X] The issue exists in the current version of the webui
[X] The issue has not been reported before recently
[ ] The issue has been reported before but has not been fixed yet

What happened?

When using Adetailer during the inpaint process, the webui throws an error and aborts the process. (I've reported a similar issue with Adetailer back in the day that got fixed here)

The inpaint feature with Adetailer was working correctly in previous versions of ReForged, but ever since updating to the latest commit, I got the following error.

Adetailer + Inpaint seems to work fine with some Adetailer detectors, but bugs out when using "Anzhc's BeautifEYEr" (Not 100% certain if this is error occurs with all Adetailer detectors or with this one specially)

Steps to reproduce the problem

1) Download & install the official Adetailer extension. 2) Generate an image and send to img2img (Not sure if necessary) 3) Upscale the image and sent to inpaint (Upscaling might not be needed to produce the error) 4) Enable Adetailer and select the "Eyeful_v1.pt" Adetailer detector, (EDIT: I have also confirmed the error occurs with the standard "PitEyeDetailer-v2-seg.pt" that comes with the Adetailer installation.) other image settings shouldn't matter, mask the eyes of course. (Inpaint Area: Only Masked or Full Picture produce the same error) 5) Wait for the usual Adetailer process to begin, it will seem to start before aborting with a long error message, followed by "RuntimeError: Inference tensors do not track version counter." in the console.

What should have happened?

Something broke along the way with the current updates, I'm not sure which commit was it.

What browsers do you use to access the UI ?

Mozilla Firefox

Sysinfo

sysinfo-2024-08-10-09-08.json

Console logs

https://pastebin.com/K7a3q3uw

Additional information

No response

Panchovix commented 2 months ago

Hi there, this is an interesting issue since main branch is really similar to OG Forge was before the experimental updates.

Can you pin-point me since which commit started to happen? Did you update Adetailer recently?

Vinzero-SS commented 2 months ago

Hi there, this is an interesting issue since main branch is really similar to OG Forge was before the experimental updates.

Can you pin-point me since which commit started to happen? Did you update Adetailer recently?

I think my previous version was "e7fa9a606769be2143f7b8d58fa1a104d2469bd8" but I'm not 100% certain, it had been about a week or two since I last updated. Right now I'm using the latest version of the normal main branch.

I also haven't updated Adetailer between when it last worked and when the error started to occur (I'm using the same\latest version.) It's the same version of Adetailer that worked previously on a different commit.

Panchovix commented 2 months ago

If you test this commit https://github.com/Panchovix/stable-diffusion-webui-reForge/commit/e99cd06312a58c4b35f1575d8070fab2bf033439

does it work fine? maybe can be related to processing.py changes from A1111 upstream

Panchovix commented 2 months ago

Okay, I have done a commit as well now, to choose a processing logic, the OG one from Forge/reForge and one from reForge upstreamed to A1111.

The OG one should work fine with Adetailer on your case, can you confirm me please?

Vinzero-SS commented 2 months ago

Okay, I have done a commit as well now, to choose a processing logic, the OG one from Forge/reForge and one from reForge upstreamed to A1111.

The OG one should work fine with Adetailer on your case, can you confirm me please?

I can confirm the new commit works with Adetailer + inpainting again.

Something a bit odd I noticed, but might be hyper-specific to the image is, before, during the commit that was broken, Adetailer would detect both eyes, but would break right after.

Now with the latest commit, Adetailer only detects a single eye under the exact same conditions (Inpaint Area: Only Masked) but at least it works. (If I use Inpaint Area: Full picture, it does detect both eyes, but I found it weird that Only masked didn't when it previously did.)

It might not have anything to do with your changes and might be hyper-specific to the image itself, I just figured it was odd and I should mention it.

I haven't done further testing at the moment with Adetailer under different conditions (txt2img\img2img for example), if anything else is broken, I will update this thread.

Panchovix commented 2 months ago

Great! Closing the issue for now.

On Settings -> SD Processing you can find the OG Forge processing (that you are probably using now) and the A1111 one (that gave that issue). Probably it is related something to latest updates from there. Also, in the case that adapter gets updated, the A1111 one should work good (if it does changes based on processing changes)

If you find issue, you're open to re-open this issue.

Panchovix / stable-diffusion-webui-reForge