DominikDoom/a1111-sd-webui-tagcomplete

Fork 0

mirror of https://github.com/DominikDoom/a1111-sd-webui-tagcomplete.git synced 2026-11-05 00:17:25 +00:00

[GH-ISSUE #311] Feature Request: Suggest tags from multiple lists #219

New issue

Open

opened 2026-10-30 21:21:10 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

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

Owner

Originally created by @feffy380 on GitHub (Jan 3, 2025).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/311

We now have at least two popular model lines (Pony Diffusion and NoobAI) that were trained with a mix of danbooru and e621 data. The way the extension currently works, you can choose danbooru or e621 tags but to get both you need a third tag list that merges both.

It might make more sense to give users the option to enable multiple tag lists at once.
UI could be similar to the way you configure Quicksettings. This also lets users define which tags to prioritize in case of conflicts.
The autocomplete popup would need to indicate in some way which file a tag comes from.

Originally created by @feffy380 on GitHub (Jan 3, 2025). Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/311 We now have at least two popular model lines (Pony Diffusion and NoobAI) that were trained with a mix of danbooru and e621 data. The way the extension currently works, you can choose danbooru or e621 tags but to get both you need a third tag list that merges both. It might make more sense to give users the option to enable multiple tag lists at once. UI could be similar to the way you configure Quicksettings. This also lets users define which tags to prioritize in case of conflicts. The autocomplete popup would need to indicate in some way which file a tag comes from.

bsakaguchi added the

enhancement

label

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

bsakaguchi commented

2026-10-30 21:21:11 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jan 3, 2025):

I'm not opposed to this, merged lists were just always cleaner in my opinion (of course worse from a UX standpoint).
The biggest issue with the multiselect approach is that categories aren't consistent between boorus.

For example, danbooru uses

0 general
1 artist
3 copyright
4 character
5 meta

And e621

0 general
1 artist
3 copyright
4 character
5 species
6 invalid
7 meta
8 lore

While the first few are the same, e621 has more in total than danbooru and maps meta tags to a different number.
With Derpibooru, the difference is even bigger.

A good merged list could map these categories to a unified format, but a multiselect dropdown can't, which would result in inconsistent coloring. There are also some inconsistencies with tags that are aliased on one booru but not the other, which could result in duplicate listings for some tags.
For example: searching for very_long_hair will show separate entries for very_long_hair (danbooru) and very_long_hair -> long_hair (e621). A source attribution display could help with that, but at the end the duplication is still unnecessary here.

Of course, a valid outcome would be to just accept and ignore those issues since they're not that fundamental.

@DominikDoom commented on GitHub (Jan 3, 2025): I'm not opposed to this, merged lists were just always cleaner in my opinion (of course worse from a UX standpoint). The biggest issue with the multiselect approach is that categories aren't consistent between boorus. For example, danbooru uses ``` 0 general 1 artist 3 copyright 4 character 5 meta ``` And e621 ``` 0 general 1 artist 3 copyright 4 character 5 species 6 invalid 7 meta 8 lore ``` While the first few are the same, e621 has more in total than danbooru and maps meta tags to a different number. With Derpibooru, the difference is even bigger. A good merged list could map these categories to a unified format, but a multiselect dropdown can't, which would result in inconsistent coloring. There are also some inconsistencies with tags that are aliased on one booru but not the other, which could result in duplicate listings for some tags. For example: searching for `very_long_hair` will show separate entries for `very_long_hair` (danbooru) and `very_long_hair -> long_hair` (e621). A source attribution display could help with that, but at the end the duplication is still unnecessary here. Of course, a valid outcome would be to just accept and ignore those issues since they're not that fundamental.

bsakaguchi commented

2026-10-30 21:21:11 +00:00

Author

Owner

@feffy380 commented on GitHub (Jan 3, 2025):

Fair enough. It sounds like it's easier to use a merged list than doing it on the fly. It also turns out someone has already created a merged list and a script to generate it. Feel free to close

@feffy380 commented on GitHub (Jan 3, 2025): Fair enough. It sounds like it's easier to use a merged list than doing it on the fly. It also turns out someone has already created a [merged list and a script to generate it](https://civitai.com/models/950325/danboorue621-autocomplete-tag-lists-incl-aliases-krita-ai-support). Feel free to close

bsakaguchi commented

2026-10-30 21:21:11 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jan 3, 2025):

Thanks, I was already aware of that list and am considering to add it to this repo too since the author also provided a clean category mapping: https://github.com/DraconicDragon/dbr-e621-lists-archive/tree/main/tag-lists/danbooru_e621_merged. Meaning it's a good merge with the mentioned unified format and the category mismatches won't affect it.

But I'm also fine with keeping this issue open as an alternative solution. A multiselect wouldn't change how single or merged lists work, so it would still be a good alternative for users that have multiple (custom) lists with matching categories or don't care about a slight mismatch.
Maybe also with predefined category re-mappings to choose from for the popular boorus or even custom editable mappings.

@DominikDoom commented on GitHub (Jan 3, 2025): Thanks, I was already aware of that list and am considering to add it to this repo too since the author also provided a clean category mapping: https://github.com/DraconicDragon/dbr-e621-lists-archive/tree/main/tag-lists/danbooru_e621_merged. Meaning it's a good merge with the mentioned unified format and the category mismatches won't affect it. But I'm also fine with keeping this issue open as an alternative solution. A multiselect wouldn't change how single or merged lists work, so it would still be a good alternative for users that have multiple (custom) lists with matching categories or don't care about a slight mismatch. Maybe also with predefined category re-mappings to choose from for the popular boorus or even custom editable mappings.

bsakaguchi commented

2026-10-30 21:21:11 +00:00

Author

Owner

@feffy380 commented on GitHub (Jan 3, 2025):

Neat. Thanks for pointing out the merged file. If you do add it, it should also be possible to link to both wikis (danbooru if category ≤ 5, else e621)

@feffy380 commented on GitHub (Jan 3, 2025): Neat. Thanks for pointing out the merged file. If you do add it, it should also be possible to link to both wikis (danbooru if category ≤ 5, else e621)

bsakaguchi commented

2026-10-30 21:21:11 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jan 3, 2025):

Yeah, I just want to ask the author first if he's ok with it.

@DominikDoom commented on GitHub (Jan 3, 2025): Yeah, I just want to ask the author first if he's ok with it.

bsakaguchi commented

2026-10-30 21:21:12 +00:00

Author

Owner

@Panchovix commented on GitHub (Jan 5, 2025):

Just wanted to say many thanks for the merged list! Helps a lot with noob based models.

@Panchovix commented on GitHub (Jan 5, 2025): Just wanted to say many thanks for the merged list! Helps a lot with noob based models.