Bug: Issue with dynamic prompts + hi-res fix + batch count > 1 (in A1111 / unclear beyond that)

[shiverczar]

When using the A1111 UI to run stable diffusion, if you utilize dynamic prompts and hi-res fix with a batch count greater than 1, the dynamic prompts will be evaluated and saved/re-used in an unexpected manner.

I didn't test with batch SIZES greater than 1, unclear if it would impact the operation.

The first image will have its prompt evaluated and replaced properly, and utilized for both the initial generation and the hi-res fix. This is expected and desired behavior.

Images 2+ will have their prompt evaluated and replaced correctly, and utilized in the initial generation (good). The hi-res fix for images 2+ will all utilize the prompt from image 1 (bad).

Example, batch count 3 - The dynamic prompt will be """""randomly""""" evaluated in the example ;)
Prompt:
A {red|green|blue} flower grows in a pot

Image 1 base prompt: A red flower grows in a pot / Image 1 hi-res prompt: A red flower grows in a pot
Image 2 base prompt: A green flower grows in a pot / Image 2 hi-res prompt: A red flower grows in a pot
Image 3 base prompt: A blue flower grows in a pot / Image 3 hi-res prompt: A red flower grows in a pot

Having simple colors mix like this may not be a big deal - and with an image of a flower it may even come out well, but in larger and more complicated dynamic prompts it can be pretty problematic.

---

I will be the first to admit I am utterly clueless on how all of this works, but I believe replication of the issue should be straightforward. Just generate with some dynamic prompting, hi-res fix enabled, a batch count > 1, and toss the second or later image into PNG info -> send to txt2img to confirm

---

Workaround: Don't generate more than 1 batch at a time -- hi-res fix will use the base prompt for each image as expected. Generate Forever will not have the same problem, as it's the same as just generating 1 image at a time and then telling the UI to do it again after it's finished.

---

Generated a batch count 3 of my example. More-or-less default settings.

It evaluated the color for each as: blue/red/red.

Threw the third image into PNG Info:

As you can see, it saved 'a red flower in a pot' as the prompt, saved the template, and saved 'a blue flower in a pot' which was incorrectly added to it as the hires prompt, saved from the first batch of the 3 batch count.

It didn't seem to affect the image much in this case, it's clearly a red flower and there's no real influence of blue - maybe the pot in front? It was a very obviously green pot in the pre-hires-fix image (I have my A1111 set to save a copy of the image as-is before going into hires), it's now a sort of blue-green/gray.

[souljadogg]

Same issue, image1 - ok, starting from the second one - in hi-res fix all the prompts are from the image1, any solutions?

[Panchovix]

Issue still persist as nov 2024

[souljadogg]

I found a solution/compromise, just using other wildcards: stable-diffusion-webui-wildcards

cons: "|" does not work, using text files

[Panchovix]

The compromise is like not being able to use dynamic prompts on wildcards? like
{__wildcard1__|__wildcard2__}

[souljadogg]

Yep, but it works fine with 69kb files (tested), biggest I have.

[Panchovix]

But do you use it alongside with dynamic promtps extension? Don't they collide each other?
Also I guess if it works on that implementation, that somehow could be adapter to fix dynamic prompts (a big if though)

[souljadogg]

Nope, I disabled dynamic promtps.

[ThePsydevil888]

Just tried updating and I'm still having the same issue. When generating with batch count > 1 it uses the prompt from the first image as the hires prompt for every other image you generate after the first. This has been messing my generations up for a while without me realising.

I really hope this can be fixed soon, it basically ruins batch count with hires as it is now.