[Request] negatives in <!..!> that are inside weights and prompt edits should remain inside them when added to negative prompt

[rubberbaron]

Intro:

To me this is a bug, but I imagine most people won't care so I classified it as a feature request.

I have a half-written fix for the following. If you're willing to accept a pull request for this, I'll integrate it into your extension, but if not I'm going to have to make a brand new "competing" extension. Up to you. BTW, I'm the author of this A1111 feature request https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/7986 which AFAIK first suggested the idea.

Description:

If you write a wildcard file HAIRCOLOR like:

blonde
strawberry blonde <!strawberry!>
brunette

and then you invoke the wildcard with __HAIRCOLOR___, everything is fine. But if you invoke the wildcard with (__HAIRCOLOR__:0.5), then (strawberry blonde:0.5) is added to positive prompt, but strawberry is added to the negative prompt, rather than (strawberry:0.5).

That case isn't the end of the world, but here's a specific case where I need this to work "right" (and I'm sure there's others): One thing I do sometimes is get an image whose basic composition I like, then I set it up so I can regenerate with the original seed. and then I prompt edit with something like [original prompt:new prompt:0.2]. That way, the first 20% of the processing repeats as original, giving the original composition, and then the new prompt takes over. However, if the new prompt has __HAIRCOLOR__ in it, then it may generate strawberry in the negative prompt, and that applies even during the first 20%, and now that first 20% doesn't actually reproduce the original image exactly.

Solution:

The fix for this is to write a real parser that parses the nested structures, and wraps the negative additions in the same structures. For example, [ ab | cd | ef <!blah!> | gh ] currently would just add blah to negative, but in my approach it would add [ | | blah | ]

I currently have an implementation of the naive wrong stuff in my (private) wildcards extension, but I've written a new version with a full parser that's mostly done. Right now, I only support adding at begin / end, I'm not sure what the positional stuff does exactly, and I'm not sure I want to try to figure out how to make it work within my logic, but if you think it's important I'll look at it.

Anyway, it's a fair amount of code, which is one reason you might not want to accept it. Here's a screenshot so you can get a sense of how much code there is, though some of it is still being tweaked, and it hasn't been run or debugged yet, I've never tried running it. (But I do have the same parser running in my wildcards extension for other purposes, so that part I'm confident about.)

[acorderob]

I considered using a proper parser when i created the extension, but i deemed it unnecessary for the common use case. But i will give it additional though to see if i can support your use cases.

[acorderob]

I hope this new release (v2.0.0) works for you.

[rubberbaron]

neat, i will give it a try