feat: add support for image embeddings

[wbruna]

This adds a new configuration parameter for the embeddings directory, and propagates it to sd.cpp.

I had to change sd.cpp to discard previous embeddings when preparing an inference, or the context would "remember" those for subsequent image generations. Since this can't really be properly tested without reusing the context, I believe it makes more sense to include it on Koboldcpp first.

(And because of leejet/stable-diffusion.cpp#656, it may be reasonable to either disable this for SDXL, or include stduhpf's fix locally too...)

[LostRuins]

Cool, I did see embeddings when I did my previous merge, but as I could not find a use case for them I didn't merge it. What would this be useful for? I believe we already have feature parity with A1111 like UIs

[wbruna]

They help with specific concepts that may be underrepresented in the model's training data, or challenging to describe. The most popular are probably negative embeddings for guiding the generation away from low-quality images (for instance, "bad hands" embeddings are especially useful for SD 1.5).

[LostRuins]

Hmmm, but can they be created from the negative prompt? We do already have a negative prompt field.

I'm trying to avoid the clutter of having too many different file dependencies. An embedding file is unlikely to be used by 99% of people, and will likely be a confusing entry to most.

Especially the current implementation in sd.cpp reads files from a directory at runtime which is not suitable for kcpp, since the server should not be dynamically loading resources, otherwise it can crash on I/O issues - that's why I ditched the LoRA dir and only allow static LoRAs.

[wbruna]

Hmmm, but can they be created from the negative prompt? We do already have a negative prompt field.

These are pre-existing embeddings, loaded and used pretty much like LoRAs. The loaded embedding vector replaces its trigger word at the prompt (or negative prompt).

An embedding file is unlikely to be used by 99% of people, and will likely be a confusing entry to most.

Actually, people used to SD 1.5 could expect those to work by default. For instance (just picking a random popular model): all Dreamshaper's example images on its Civitai homepage (https://civitai.com/models/4384/dreamshaper) have the "BadDream" embedding (https://civitai.com/models/72437?modelVersionId=77169 , by the model's author) on the negative prompt.

On the other hand...

Especially the current implementation in sd.cpp reads files from a directory at runtime which is not suitable for kcpp, since the server should not be dynamically loading resources, otherwise it can crash on I/O issues - that's why I ditched the LoRA dir and only allow static LoRAs.

... yeah, that's kind of unavoidable with the current code. It could be changed to preload a few embeddings beforehand (even the biggest ones have usually less than half a megabyte), and only apply the weights during inference, but that'd be a pretty big diff to keep outside sd.cpp :-(

[LostRuins]

Thanks but I think I will hold off on this PR for now, can keep it in mind for future.