The Prompt Postprocessor for Stable Diffusion WebUI, formerly known as "sd-webui-sendtonegative", is an extension designed to process the prompt after other extensions have potentially modified it. This extension is compatible with the AUTOMATIC1111 Stable Diffusion WebUI and SD.Next.
Currently this extension has these functions:
Note: The extension must be loaded after the installed wildcards extension (or any other that modifies the prompt or has it's own syntax expressions). Extensions load by their folder name in alphanumeric order.
With the "Dynamic Prompts" extension this happens by default due to default folder names for both extensions. But if this is not the case, you can just rename this extension's folder so the ordering works out.
With the "AUTOMATIC1111 Wildcards" extension you will have to rename one of the folders, so that it loads before than this extension.
When in doubt, just rename this extension's folder with a "z" in front (for example) so that it is the last one to load, or manually set such folder name when installing it.
Notes:
It only recognizes regular A1111 prompt formats. So:
\[prompt\] (prompt) (prompt:weight)
\[prompt1|prompt2|...\]
\[prompt1:prompt2:step\]
\<kind:model...\>
prompt1 BREAK prompt2
prompt1 AND prompt2
In SD.Next that means only the A1111 or Full parsers. It will warn you if you use the Compel parser.
This extension should run after any wildcard extensions, so any remaining wildcards present in the prompt or negative_prompt at this point of processing must be invalid. Usually you might not notice this problem until you check the image metadata, so this option gives you some ways to detect and treat the problem.
If you choose to not ignore wildcards, the extension will look for any __wildcard__ or {choice|choice} constructs and act as configured.
The extension uses now a new format for its commands. The format is similar to an extranetwork, but it has a "ppp:" prefix followed by the command, and then a space and any parameters (if any).
<ppp:command parameters>
When a command is associated with any content, it will be between an opening and a closing command:
<ppp:command parameters>content<ppp:/command>
The set
and if
commands are the first to be processed.
This command sets the value of a variable that can be checked later.
The format is:
<ppp:set varname>value<ppp:/set>
This command prints the value of a variable.
The format is:
<ppp:echo varname>
This command allows you to filter content based on conditions.
The format is:
<ppp:if condition1>content one<ppp:elif condition2>content two<ppp:else>other content<ppp:/if>
The conditionN compares a variable with a value. The operation can be eq
, ne
, gt
, lt
, ge
, le
and the value can be a quoted string or an integer.
The variable can be one set with the set
command or special variables like:
_sd
: the loaded model version ("sd1"
, "sd2"
, "sdxl"
)Any elif
s (there can be multiple) and the else
are optional.
(multiline to be easier to read)
<ppp:if _sd eq "sd1"><lora:test_sd1> test sd1
<ppp:elif _sd eq "sd2"><lora:test_sd2> test sd2
<ppp:elif _sd eq "sdxl"><lora:test_sdxl> test sdxl
<ppp:else>unknown model
<ppp:/if>
Only one of the options will end up in the prompt, depending on the loaded model.
The new format for this command is like this:
<ppp:stn position>content<ppp:/stn>
Where position is optional (defaults to the start) and can be:
The format of the insertion point to be used in the negative prompt is:
<ppp:stn iN>
If the insertion point is not found it inserts at the start.
You have a wildcard for hair colors (__haircolors__) with one being strawberry blonde, but you don't want strawberries. So in that option you add a command to add to the negative prompt, like so:
blonde
strawberry blonde <ppp:stn>strawberry<ppp:/stn>
brunette
Then, if that option is chosen this extension will process it later and move that part to the negative prompt.
The old format is still supported (for now) and is like this:
<!content!>
And an optional position can be specified like this:
<!!position!content!>
With the insertion point like this:
<!!iN!!>
Positional insertion commands have less priority that start/end commands, so even if they are at the start or end of the negative prompt, they will end up inside any start/end (and default position) commands.
The content of the negative commands is not processed and is copied as-is to the negative prompt. Other modifiers around the commands are processed in the following way.
They will be translated to the negative prompt. For example:
(red<ppp:stn>square<ppp:/stn>:1.5)
will end up as (square:1.5)
in the negative prompt(red[<ppp:stn>square<ppp:/stn>]:1.5)
will end up as (square:1.35)
in the negative prompt (weight=1.5*0.9)(red<ppp:stn>[square]<ppp:/stn>:1.5)
will end up as ([square]:1.5)
in the negative prompt. The content of the negative tag is copied as is, and not joined with the surrounding modifier.Negative commands inside such constructs will copy the construct to the negative prompt, but separating its elements. For example:
[red<ppp:stn>square<ppp:/stn>|blue<ppp:stn>circle<ppp:/stn>]
will end up as [square|], [|circle]
in the negative prompt, instead of [square|circle]
[red<ppp:stn>square<ppp:/stn>:blue<ppp:stn>circle<ppp:/stn>:0.5]
will end up as [square::0.5], [:circle:0.5]
instead of [square:circle:0.5]
This should still work as intended, and the only negative point i see is the unnecessary separators.
MIT
If you have any questions or concerns, please leave an issue, or start a thread in the discussions.