[Suggestion] Can we have embeddings autocomplete without adding <e: before?
VL4DST3R opened this issue · comments
I can see this making sense for lora/lyco, since that's how they are defined inside the prompt and added via the extra networks menu, but embedding trigger words are written as-is, and it feels quite unintuitive to use lora/lyco-like syntax for them as well.
I know this was probably done for ease of implementation, but figured it's worth asking regardless for a nicer user experiece. Otherwise this extension is pretty much flawless in my book and I've been using it since its inception.
This was initially left over from the original webui implementation. Embeddings used the <> syntax for quite a while, way before Loras were a thing. Although they quickly became optional (or even always were, not sure about that).
The main reason I keep them separate from normal tags nowadays is the difference in sorting.
Tags are sorted by their post count so that common tags are higher, but embeddings alphabetically.
Due to this they are hard to mix, similar to the extra tags they would need to be appended at the start or end. Since the embedding list can be much longer, this makes browsing for them hard if mixed with normal results.
Having said that, if you have "Show all results" enabled, I guess it could work. The tricky part there is just how to handle very long lists that get loaded on demand if the end is reached, since embeddings added to the end of the list would mess with the mechanism. But I'll have a look and see if I can work it out.
Can't you add embeddings to the top? For most people embeddings are words wildly different from the regular tokens one would use to describe images (for obvious reasons) so plonking the embeddings that match what the user is typing above regular tag autocomplete results would seem like the best approach.
Also yes, had show all results since i started using this.
The issue there is mainly that a long embedding list could push the normal tags out of view if they come first and the search is short enough. Embeddings use a more generic matching rule, so it will also find the middle of words etc.
Even longer words can still be an issue, for example I have a lot of embeddings ending in "style", which completely push away normal results for things like "hair style". So a minimum length before including them won't really work either.
Implementation wise adding them to the start would definitely be easier, just not sure if it's a good tradeoff.
There is no control over how the searching behavior itself operates? I figured you could just look from the beginning of the word or following capitalization?
Funny enough I've read recently how Minecraft switched from its previous search where it would basically do what you describe, list results with the group of letters inside the word itself to now only display those that start with it.
The normal tags do that, but not the embeddings / lora / lyco. Mainly since a lot of them use cryptic prefixes or add the creator name to make them distinctive from normal tags. Quite a few don't separate these at all from the rest of the word in the default name, which hinder the "only search for the start of the word" approach. And while I currently don't look at capitalization anyway, some of them don't even do that much and are all lowercase, all written together.
But I think I have found a good workaround for the issue. If the embeddings are included in the normal search, they will come first and push everything down, but not count towards the set maximum, so it will work without "Show all results". And to mitigate annoying scrolling, I added a new functionality to the End key. If the embedding list is particularly long, hitting End once will select the first non-embedding result, and on a second press the actual last result. So you can quickly jump between the sections using End and Home, even if they are part of the same list and differently sorted.
Yeah fair point about people being stupid about their names, been an issue with loras especially, with people naming them stupidly generic things or not differentiating between versions properly. Your workaround sounds great, is it public already? Can i test it?
Testing a few edge cases to make sure it works, should be ready in a few minutes.
You can use it now by enabling this new option:
As a general side note that is also true for all other long lists, the "How many results to load at once" setting still applies here. So if a search returns more than that number of embeddings, you might have to press End multiple times until the first non-embeddings get loaded.
Works great but have you toggled Active in txt2img to be off by default? I couldn't figure out why it wasn't working at all anymore and turns out it was entirely disabled.
Also quick question regarding list limit- is limiting the list really that big of an issue? What happens if you do indeed have hundreds of hits, is there really a substantial performance impact?
have you toggled Active in txt2img to be off by default?
No, all "Active in" settings are on by default. And even then, an update to the extension wouldn't influence your applied settings, so you must have deactivated them yourself by accident somehow.
What happens if you do indeed have hundreds of hits, is there really a substantial performance impact?
Especially with Show all results, the list was really laggy for the first few keystrokes until it gets further narrowed down. The lag actually mostly comes from the creation of the list elements themselves / them being added to the page, so it froze the whole site for a brief moment, which would also lag out the typing itself (which obviously feels very bad and annoying).
This is hard to work around since HTML DOM manipulation is synchronous by design, I have no influence on how fast the browser can update & render it. Adding thousands of list elements at once was just too much, so either a delayed adding in chunks or load on demand was needed. The latter was chosen because most of the time the user doesn't need to load more and is just still in the progress of typing their query.
The default limit is on the lower side with 100 loaded at once, mostly just so low performance clients like laptops and mobile phones that access a shared instance don't lag out. You can try raising it and see how it performs, on a desktop it shouldn't be too much of an issue to go higher.
Thanks for the in-depth explanation. I also never needed it higher than 100 but good to know how it works. Thanks again for the fast response and addition!