Danbooru Image Search

Danbooru Image Search is the reason this pack exists. Everything else in it is scaffolding around this one idea: instead of guessing Danbooru tags by hand, you throw a prompt, an image, or both at a semantic search index and get back actual matching posts, already downloaded and ready to wire into your workflow. Reverse-image search, tag-driven search, negative-prompt control - it's the node you'll reach for when you want reference images that match, not references you settle for.

Danbooru, if you haven't met it, is the anime imageboard whose crowd-tagged archive became the standard training corpus for the whole SDXL anime ecosystem. Its tags are the prompt vocabulary of Illustrious, NoobAI, and Pony. This node searches a frozen 2022 embedding snapshot of that board, which means the results speak the exact language those models were trained on - perfect reference material for style LoRAs, IPAdapter sets, or just finding "that character in this pose".

How it works

The pipeline has three stages. First it builds a query vector from whatever you gave it: an image gets embedded through the wd14 tagger (dghs-imgutils), and tags get embedded through an ONNX text encoder (clip_text.onnx or siglip_text.onnx - the model_type switch). Here's the clever fallback: if the ONNX encoder or tag index isn't available, tag_embedding_mode can drop to hash_only, which builds deterministic 1024-dimensional vectors from a SHA-256 hash of each tag. No model needed, fully offline, stable across runs. The auto default tries ONNX first and falls back per-tag.

Then it combines positives and negatives. combine_strategy offers two flavors: Balanced normalizes the positive side and negative side separately, then subtracts negatives - the sane default. Stepwise de-overlap adds and subtracts sequentially, orthogonalizing each step to avoid the negative canceling out something the positive said. Two modifier booleans, tag_new_info_only and reduce_negative_overlap, push the same idea further: only add tag information the image vector doesn't already carry, and only subtract negative components that don't overlap the positive mix. These are precision dials for people fighting fuzzy results; you can ignore them for a long time.

Finally it searches a FAISS cosine index over millions of Danbooru 2022 image embeddings, takes the top candidate post IDs, then fetches each post's metadata (API first, HTML fallback - the same fetch_mode dance as the pack's other nodes) and downloads the images.

Inputs and outputs that matter

A beginner needs four things:

• positive_prompt - the main input. Comma-separated Danbooru tags (touhou, reimu_hakurei) or a text description.
• positive_image - plug an image in and it becomes reverse-image search. Want "more like this"? This is the field.
• negative_prompt - subtract semantics. monochrome, sketch pushes those looks away.
• max_images (1–50, default 4) and download_size (preview → thumbnail → large → full, attempts progressively larger variants).

The image_weight / tag_weight floats (0–4) let you tilt the blend toward the image or the tags; idf_weight_tags down-weights common tags using frequency counts from selected_tags.csv. Nice tools, not prerequisites.

Outputs: IMAGE (a list - batch-feed it into img2img or IPAdapter), URLS (list, for provenance and manual checks), IDS (aggregated post IDs), TAG (the first post's tags - handy for building a prompt from what the search actually found), plus IMG_WIDTH / IMG_HEIGHT.

Install

ComfyUI Manager → "Danbooru FAISS Search", or:

cd ComfyUI/custom_nodes
git clone https://github.com/L33chKing/ComfyUI-danbooru-FAISS-search
cd ComfyUI-danbooru-FAISS-search
pip install -r requirements.txt

This is the node that makes installs slow: faiss-cpu, onnxruntime, timm, and dghs-imgutils are all real dependencies. First execution downloads the FAISS index and the ONNX text encoder from HuggingFace (hundreds of MB) - give it a minute and don't panic when it looks hung.

Gotchas

Danbooru's API rate-limits anonymous users hard; if you're searching a lot, put your api_username / api_key in (free, higher limits). And the index covers the entire board, including explicit content - there's no safe-mode filter, so results can be NSFW. Finally, the auto fetch mode can be slow on big result sets; if a post 404s, extra_api_search (0–1000) tells the node how many extra candidates to pull in to backfill. Start at 0, raise it if you're seeing gaps.