Per-tag workflow settings
Opened this issue · 0 comments
I'm not sure how useful this feature would be in general but it would help in the case of the default workflow which has a lot of parameters
It's a common need for me to change settings between normal and upscale gens. I end up generating some, tweaking a few parameters and hitting Upscale
, then manually dragging them back to generate with txt2img again. This is how I get the best results.
I just want a way to hit Upscale
with the settings for both subgraphs predefined, and the ability to copy between the two separate sets. Three ways of doing this I can think of:
- Rewrite the entire default workflow to have two copies of all the parameters/nodes, have a tab to switch between the two. Can be done without any extra code but it's pretty arduous and results in a lot of duplication
- Have a way to create "layers" of settings that are transparent and only copied if a matching workflow is queued. In that case the base value of the widget will be temporarily overridden with the subgraph layer's. You'd switch on "settings for HR mode" globally and all the parameters change color, changing any of the parameters marks it as overridden for that layer the moment it detects the subgraph being executed
- Leverage the settings stack (#80). Start a new session and pick the settings you want for first pass. Then push on a new stack and pick the settings for second pass. Keep only the diff of the settings for the second HR pass so when changing the first group of settings, the second group will "lock" any unchanged parameters to the first group. You'd need to change between the settings yourself but it's a one-click operation instead of fiddling with lots of widgets
I think if option 1 is went with there are good ways and bad ways of going about it. One way (good or bad) might be gathering up all the parameters and sticking them into one big "panel component" subgraph then feeding them out to individual subgraphs. But that needs to take into account switching all the values of the parameters when the tab/mode is changed. I vaguely remember some REAKTOR ensembles doing something like making one giant macro with all the frontend widgets grouped together but I don't know if they go as far as what I propose
I don't know if option 2 is any better than duplication. It could cause lots of edge cases to arise when dealing with the future settings stack (#80). Worse is it's incompatible with frontend nodes. A lot of the frontend logic takes into account the current value of the widgets for parameter transformation. Replacing the value of the widget at prompt time will cause inconsistencies unless a delay is inserted. Even with that there are some parameters it wouldn't make sense to make layerable like uploaded images
Option 3 sounds most sensible since I know I will need parameter restoration and quick configs like https://github.com/Zyin055/Config-Presets for webui, that could be built out as another variant of how it's used. Save a fragment of the current settings to apply on top if the user picks them. Only real issue is it's not going to be applied automatically when hitting "Upscale" since the params will need to be switched between but at least this is much better than having to tinker with every single frontend widget to get them back to the first state by hand. And because the settings are applied manually there's less chance for race conditions since between the two actions the graph can propagate the settings