[GH-ISSUE #137] [Suggestion] White/blacklist models on a per-tagfile basis #100

New issue

Closed

opened 2026-10-30 21:19:13 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-30 21:19:13 +00:00

Owner

Originally created by @tofof on GitHub (Mar 10, 2023).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/137

It'd be very nice if this extension could automatically select the appropriate tag file based on which model was loaded. This would make it substantially more convenient for users with some models based on danbooru and other models based on e621.

I think the most straightforward way to do this would be to simply take the current whitelist/blacklist implementation and make it tagfile-specific.

Current implementation

Choose either danbooru OR e621, and then add extra-quality-tags in addition, and finally whitelist or blacklist certain models for the extension to be used or not to be used.

Desired implementation

Individual white/black lists for each CSV (so, three by default). Assuming the user has, for example, WD and E18, they would:

whitelist WD for danbooru.csv
whitelist E18 for e621.csv
blacklist none for extra-quality-tags.csv

The extension behavior with those settings would be to use danbooru+extra when WD was loaded, use e621+extra when E18 was loaded, and use only extra for any other model selected.

Originally created by @tofof on GitHub (Mar 10, 2023). Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/137 It'd be very nice if this extension could automatically select the appropriate tag file based on which model was loaded. This would make it substantially more convenient for users with some models based on danbooru and other models based on e621. I think the most straightforward way to do this would be to simply take the current whitelist/blacklist implementation and make it tagfile-specific. ### Current implementation Choose either danbooru OR e621, and then add extra-quality-tags in addition, and finally whitelist or blacklist certain models for the extension to be used or not to be used. ### Desired implementation Individual white/black lists for each CSV (so, three by default). Assuming the user has, for example, WD and E18, they would: * whitelist WD for danbooru.csv * whitelist E18 for e621.csv * blacklist none for extra-quality-tags.csv The extension behavior with those settings would be to use danbooru+extra when WD was loaded, use e621+extra when E18 was loaded, and use only extra for any other model selected.

bsakaguchi closed this issue

2026-10-30 21:19:13 +00:00

bsakaguchi commented

2026-10-30 21:19:15 +00:00

Author

Owner

@DominikDoom commented on GitHub (Mar 10, 2023):

I don't think there's much benefit in this, since 90% of the models in circulation right now (If I had to take a guess) are descendants of the NAI leak which only knows Danbooru. e621 models are very niche to add so many additional options for, and having three different options might be confusing for those not using them. Also, these tag files are not hard-coded, users may very well add their own tags or make a danbooru+e621 mixed file based on the model's needs, which would require a dynamic setting in some way.

If the need to switch really comes up that often, you could just add the tag file setting to your quicksettings bar, the script already hot-reloads the tags if you change it there.

This feature or a similar implementation might become more useful if more models use different tags in the future, but in that case I would preferably add a "preset" system where users can select or type combinations, like "model name; tag file; extra file;" or something along those lines that could overwrite the default white- & blacklist. But for now as I said above I think the quicksettings are enough.

@DominikDoom commented on GitHub (Mar 10, 2023): I don't think there's much benefit in this, since 90% of the models in circulation right now (If I had to take a guess) are descendants of the NAI leak which only knows Danbooru. e621 models are very niche to add so many additional options for, and having three different options might be confusing for those not using them. Also, these tag files are not hard-coded, users may very well add their own tags or make a danbooru+e621 mixed file based on the model's needs, which would require a dynamic setting in some way. If the need to switch really comes up that often, you could just add the tag file setting to your quicksettings bar, the script already hot-reloads the tags if you change it there. This feature or a similar implementation might become more useful if more models use different tags in the future, but in that case I would preferably add a "preset" system where users can select or type combinations, like "model name; tag file; extra file;" or something along those lines that could overwrite the default white- & blacklist. But for now as I said above I think the quicksettings are enough.

bsakaguchi commented

2026-10-30 21:19:16 +00:00

Author

Owner

@tofof commented on GitHub (Mar 10, 2023):

I hadn't thought of the quicksettings bar. You're right, that's a reasonably straightforward alternative.

I'm one user who has a mix of both; there are about 6 well-developed models (independent, not descendants of one another) using e621 tags at this point, if that is a useful datapoint.

I agree it would have to be dynamic, one per .csv file that was in the folder, to support users adding their own tag files. Then again, the main reason I can imagine users adding their own tag files is to support models with unique tag schemes, which is exactly when this suggestion would be most useful.

Would you be open to a PR that implements this? I would hide the settings behind a single checkbox (something like 'automatically select tagfile depending on model') so that users aren't presented with the extra complexity until they opt-in.

@tofof commented on GitHub (Mar 10, 2023): I hadn't thought of the quicksettings bar. You're right, that's a reasonably straightforward alternative. I'm one user who has a mix of both; there are about 6 well-developed models (independent, not descendants of one another) using e621 tags at this point, if that is a useful datapoint. I agree it would have to be dynamic, one per .csv file that was in the folder, to support users adding their own tag files. Then again, the main reason I can imagine users adding their own tag files is to support models with unique tag schemes, which is exactly when this suggestion would be most useful. Would you be open to a PR that implements this? I would hide the settings behind a single checkbox (something like 'automatically select tagfile depending on model') so that users aren't presented with the extra complexity until they opt-in.

bsakaguchi commented

2026-10-30 21:19:16 +00:00

Author

Owner

@DominikDoom commented on GitHub (Mar 10, 2023):

Would you be open to a PR that implements this?

Sure, although I'm not sure how easy it is to make settings dynamic or hide them, at least not without restarting inbetween.
Every other extension I've seen just uses a pre-set number of selections instead of dynamic additions, so it might be complicated to do with how gradio works. I'm no expert in that, though.

@DominikDoom commented on GitHub (Mar 10, 2023): > Would you be open to a PR that implements this? Sure, although I'm not sure how easy it is to make settings dynamic or hide them, at least not without restarting inbetween. Every other extension I've seen just uses a pre-set number of selections instead of dynamic additions, so it might be complicated to do with how gradio works. I'm no expert in that, though.

bsakaguchi commented

2026-10-30 21:19:17 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jun 10, 2023):

Closing as stale, feel free to reopen or create a PR if you have a concrete implementation in mind. As suggested originally, it's a bit out of scope like I said.

@DominikDoom commented on GitHub (Jun 10, 2023): Closing as stale, feel free to reopen or create a PR if you have a concrete implementation in mind. As suggested originally, it's a bit out of scope like I said.