Shared context between prompt and ADetailer prompt possible?

[pmcculler]

Defining something like ${EyeColor=blue} means I can use ${EyeColor} as a variable after that in the prompt just fine, but if I try to access the variable in the ADetailer prompt, I get 'no such variable in context' (paraphrasing, it's been a bit). I'd very much like to have this so I can, specifically, provide details like eye color and facial expression to both prompts without just repeating it.

[Nrgte]

I'd be interested in this as well!

[magestyx]

This is a really essential feature to making this workflow function properly. As-is, Dynamic Prompts is great and ADetailer is great but they're almost useless combined.

[adieyal]

@akx What do you think about storing context variables in a module-scoped variable? That way other extensions can access variables if they want to. There have been previous requests for global variables. We should also share contexts between positive and negative prompts.

[akx]

@adieyal Sounds icky.

Better store them in the p object in some well-defined way, I think?

[adieyal]

In theory I agree with you, except that we don't have any control over it and so it could be brittle. I haven't looked in detail, but if auto1111 doesn't explicitly recognise shared state set by extensions then our variables could easily be wiped - e.g. if the p object is recreated for some reason.

[akx]

The p object is not recreated during a single processing operation -- there's been discussions on the a1111 dev discord about formalizing it a bit more (or at least giving it some dict prop for various extensions' data bags), but nothing concrete -- so it should be okay to stash an extra attribute on it.

[adieyal]

The other uncertainty is the order in which extensions are run - it's an issue regardless of how we implement it. Do you know if any one is looking into dependencies between extensions or something else the could ensure that an extension will only be run after another one?

[pmcculler]

At the moment, I can say at least that they happen to be run in alphabetical order, apparently by the name of their extensions directory. That's why I wrote 2 Javascript extensions, one to run before DP and one after, and I even locally renamed Prompt Fusion's directory so it gets run later than usual (seems to have no other important effect...). It would be interesting to have a dependency tree - certainly there are a lot of extensions, and I think the number of current ones grows faster than they become defunct. They have actual dependencies, and formalizing that would stabilize the ecosystem a bit.

[magestyx]

Any progress on this? This seems so essential. Otherwise, adetailer conflicts with the main prompt and 'muddies' the result. For instance, if the main prompt dynamically has 'blue eyes' and adetailer dynamically has 'brown eyes', with a denoise of around 50 the eyes end up a totally blah bluish-brown and not at all like they'd be with consistency. Even some kind of temporary workaround would be great in the meantime.

Here's the thread on the adetailer github regarding this issue for cross reference: https://github.com/Bing-su/adetailer/issues/62

[ryanull24]

+1 to this, would also like to see this implemented

[Nziner]

+1

[uorufu]

It is not straight forward but it should definately be possible by either using global variables or writing to txt. I got wildcards to work with adetailer with my wildcards fork.

The way prompts are sent to model in gradio makes it hard to comminucate between main prompt and adetailer prompt in a simple manner.

[Nziner]

It is not straight forward but it should definately be possible by either using global variables or writing to txt. I got wildcards to work with adetailer with my wildcards fork.

Wow, it`s work, thank you! 🔥

[magestyx]

It is not straight forward but it should definately be possible by either using global variables or writing to txt. I got wildcards to work with adetailer with my wildcards fork.

The way prompts are sent to model in gradio makes it hard to comminucate between main prompt and adetailer prompt in a simple manner.

Awesome - can't wait to try this!

[uorufu]

It is not straight forward but it should definately be possible by either using global variables or writing to txt. I got wildcards to work with adetailer with my wildcards fork. The way prompts are sent to model in gradio makes it hard to comminucate between main prompt and adetailer prompt in a simple manner.

Awesome - can't wait to try this!

Great, hope you like it.

I am working on some added functionality (specifically working on a special wildcard that simply starts at line 1 of the txt and increases the line by one for every image in a batch, going through each line one by one. It's already sort of functional (using a global variable), but there are some minor issues with it and I'll be gone the weekend so might be sometime next week. the issue right now is ' resetting' the global variable at the right time. So it restarts at 1 each batch instead of whereever you left off. Anyway, ill add it to the fork when I think it is functioning properly.

[Nziner]

Great, hope you like it.

I am working on some added functionality (specifically working on a special wildcard that simply starts at line 1 of the txt and increases the line by one for every image in a batch, going through each line one by one. It's already sort of functional (using a global variable), but there are some minor issues with it and I'll be gone the weekend so might be sometime next week. the issue right now is ' resetting' the global variable at the right time. So it restarts at 1 each batch instead of whereever you left off. Anyway, ill add it to the fork when I think it is functioning properly.

What are some problems with using a variable? If I stop the generation and start again - the variables are taken completely new.

INFO:sd_dynamic_prompts.dynamic_prompting:Prompt matrix will create 10 images in a total of 10 batches.
[*]Line 14 my_color.txt         ► silver
[*]Line 06 my_color.txt         ► green
[*]Line 04 my_color.txt         ► fuchsia
[*]Line 09 my_color.txt         ► navy
[*]Line 16 my_color.txt         ► white
[*]Line 15 my_color.txt         ► teal
[*]Line 00 my_color.txt         ► yellow
[*]Line 15 my_color.txt         ► teal
[*]Line 09 my_color.txt         ► navy
[*]Line 02 my_color.txt         ► black

[Nziner]

@uorufu Hmm. Tested some more, noticed that if nested wildcards inside files - they don't work (words or text files - doesn't matter). The original use of wildcards without "0".

The contents of the file my_test.txt {red|blue|green} eyes {purple|brown} eyes

File my_test.txt (in extensions\stable-diffusion-webui-wildcards-adetailer\wildcards folder)

Request __0_my_test__
Result "{purple|brown} eyes" or "{red|blue|green} eyes"

File my_test.txt (in extensions\sd-dynamic-prompts/wildcards folder)

Query __my_test__
Result "blue eyes"/"brown eyes"/"purple eyes"/"red eyes", etc

[Nrgte]

@uorufu Hmm. Tested some more, noticed that if nested wildcards inside files - they don't work (words or text files - doesn't matter). The original use of wildcards without "0".

Request __0_my_test__
Result "{purple|brown} eyes" or "{red|blue|green} eyes"

Have you tried:

purple|brown red|blue|green

And then have { eye_color } eyes ?

[Nziner]

@uorufu Hmm. Tested some more, noticed that if nested wildcards inside files - they don't work (words or text files - doesn't matter). The original use of wildcards without "0".

Request __0_my_test__
Result "{purple|brown} eyes" or "{red|blue|green} eyes"

Have you tried:

purple|brown red|blue|green

And then have { eye_color } eyes ?

If I change the contents of the file to red|blue|green purple|brown

It does not work either through __0_my_test__ or __my_test__ The result is "purple|brown"

[Nrgte]

What if you do something like this?

${var=!0_my_test}

[Insert prompt here] { ${var} } eyes

[Nziner]

${var=!0_my_test}

[Insert prompt here] { ${var} } eyes

Variables have nothing to do with it. Processing/retrieving nested random values within a file does not work.

[Nrgte]

${var=!0_my_test} [Insert prompt here] { ${var} } eyes

Variables have nothing to do with it. Processing/retrieving nested random values within a file does not work.

It works for me:

a portrait of a woman with f_facial/eye_color_test eyes

Content of that wildcard file:

{purple|brown}
{red|blue|green}

Generated prompt: a portrait of a woman with red eyes

But I've made customizations on my end. I think there was a bug that the order in which things get done are wrong, which I've fixed on my end.

[Nziner]

But I've made customizations on my end. I think there was a bug that the order in which things get done are wrong, which I've fixed on my end.

If you changed the script, that makes a difference. What did you change?

Only I don't see a number in your query. Without the digits, everything works fine for me. I'm talking about the @uorufu fork. Most likely you are talking about the original script.

[Nrgte]

But I've made customizations on my end. I think there was a bug that the order in which things get done are wrong, which I've fixed on my end.

If you changed the script, that makes a difference. What did you change?

I didn't change the fork, but the underlying library: https://github.com/adieyal/dynamicprompts

But I didn't use the fork, I used the normal one. I don't see why using the fork should be different in that case. All the templating and replacement is done in that library.

[Nziner]

But I've made customizations on my end. I think there was a bug that the order in which things get done are wrong, which I've fixed on my end.

If you changed the script, that makes a difference. What did you change?

I didn't change the fork, but the underlying library: https://github.com/adieyal/dynamicprompts

But I didn't use the fork, I used the normal one. I don't see why using the fork should be different in that case. All the templating and replacement is done in that library.

What did you change in dynamicprompts to make it work?

I need to save the random generation from the base prompt and have the same value used in the adetailer. I.e. if I have a girl with blue eyes in the base prompt, then blue eyes will be used in the adetailer as well. If this works for you - I will be glad if you share the solution

[Nrgte]

What did you change in dynamicprompts to make it work?

I've changed almost everything and added additional functionality. But it doesn't share any information with ADetailer. I've only changed dynamicprompts. I didn't fully understand that your issue only applies if you use the fork.

[Nziner]

What did you change in dynamicprompts to make it work?

I've changed almost everything and added additional functionality. But it doesn't share any information with ADetailer. I've only changed dynamicprompts. I didn't fully understand that your issue only applies if you use the fork.

So in the end do you have variable saving working or not? It's just that this thread is dedicated to that. If you have a solution, please share.

So far a fork that changes wildcards processing is the only working solution for me (https://github.com/uorufu/stable-diffusion-webui-wildcards-adetailer). But it's the only one that doesn't work just the dynamicprompts.

[Nrgte]

So in the end do you have variable saving working or not? It's just that this thread is dedicated to that. If you have a solution, please share.

So far a fork that changes wildcards processing is the only working solution for me (https://github.com/uorufu/stable-diffusion-webui-wildcards-adetailer). But it's the only one that doesn't work just the dynamicprompts.

Yes, I have variable sharing implemented in my version as well as some other features like regex variable replacement. But it's not pretty and requires the dynamicprompts extension at this revsion: 39c06b30409df6259c4430338123f7d4e05d8dc1 (or version 0.29.0). And at that point you can't update this extension anymore, otherwise the changes will get overwritten.

Edit: I've forked it here: https://github.com/Nrgte/dynamicprompts

[uorufu]

@Nziner

I just did a massive update on my wildcards fork, almost rewrote the entire thing and added some more functionality.

Nested wildcards don't work, I can maybe look into that next week. But my fork is from wildcards, not dynamic prompts. So it does not have the same functionality.

I literally started programming last week, I though I first tried to get wildcards to work properly with adetailer. Might look into variables later on. Sounds problematic though, considering what I have learned of the process that goes on behind the scenes when automatic1111 prepares the main promps and adetailer prompts.

[Nziner]

@Nziner

I just did a massive update on my wildcards fork, almost rewrote the entire thing and added some more functionality.

Nested wildcards don't work, I can maybe look into that next week. But my fork is from wildcards, not dynamic prompts. So it does not have the same functionality.

I literally started programming last week, I though I first tried to get wildcards to work properly with adetailer. Might look into variables later on. Sounds problematic though, considering what I have learned of the process that goes on behind the scenes when automatic1111 prepares the main promps and adetailer prompts.

That's cool. I'll check it out later. You don't have to leave the dynamic prompts work. The most important thing is to leave the work of nested wildcards. I don't have much programming experience either, but through chatgpt I managed to fix the nested wildcards handling. It is enough to recursively process the selected string in the same way. I can discount the code for a previous version of your fork, it worked. But I think you will make it cleaner and more correct.

I also started to make it possible to process expressions like {test|test2| } and in general it worked, but I stopped at multiple constructions in one line. Don't have time to do that yet either.

You can open a discussion in your fork and we can continue the discussion there. I'll try to look at it next week too.

You can also check out the fork from https://github.com/sdbds/stable-diffusion-webui-wildcards, you might find it useful.