Style Similarity

Style Similarity is the pack's second search engine, and it answers a question the tag search can't: "what does this art style look like, across the whole board?" You feed it an image, it returns the nearest matches from a large set of learned style embeddings, and those matches tend to share the drawing style even when the characters, scenes, and tags are totally different. Tag search finds "this character in this pose"; this node finds "drawn like this". For hunting style references, that distinction is everything.

It's built on someone else's work - gustproof's style-similarity model, ported into ComfyUI with an HNSW index in front of it. HNSW is a nearest-neighbor graph, which means lookups are fast once the index is built, but building it is a real first-run event (more on that below).

How it works

On first execution the node downloads two big files from gustproof's HuggingFace space: the embedding set (embs.npz, ~460 MB) and a URL list (urls.txt, ~22 MB), then loads the style-extractor checkpoint for the version you picked. It embeds your query image with that model, searches the HNSW graph for the nearest style neighbors, and returns them as images.

Two details worth knowing:

• model_version - v0.3 (default) or v0.2. v0.3 is the newer, smarter checkpoint at ~88 MB; v0.2 is the older one at ~374 MB. Default to v0.3 and only switch down if you're chasing a specific older result set.
• The index is persisted. After the first build it's cached as style_hnsw_raw.index on disk, so restarts skip the expensive rebuild. First run is the slow one.

The distance metric is raw squared L2, so lower = closer. That trips people up if they're used to cosine similarity where higher is better. If you enable overlay_similarity, the node paints the raw distance number onto each returned image - the fastest way to sanity-check whether "closest" actually looks like your query.

Inputs and outputs that matter

• input_image - required, your query. Accepts a single image or a batch, so you can query several styles at once.
• max_images - 1 to 100, default 4. The count of nearest matches.
• disable_api - default True, and this one matters. When on, the node skips the MD5→post metadata lookup entirely: it keeps the original CDN URLs and returns no post IDs. Flip it off only if you want bigger image variants (download_size) and real Danbooru post IDs, which costs API requests and time.
• download_size - preview, thumbnail, large, full - only relevant when disable_api is off, since the size upgrade goes through the API.

Outputs: IMAGE (list of matches), URLS (list, always present), IDS (post IDs - empty when disable_api is on, by design).

What to actually do with it

The obvious workflow is style reference mining: drop in a seed image, grab the top matches, and use them as a consistent reference set for IPAdapter or as candidates for a style LoRA dataset. Because the model was trained on style, a good query tends to pull a coherent-looking gallery even when the content differs. It also works as a discovery tool - "what does the model think my style is?" is a genuinely fun question to ask it.

Install and gotchas

Same pack as everything else here: ComfyUI Manager → "Danbooru FAISS Search", or git clone https://github.com/L33chKing/ComfyUI-danbooru-FAISS-search into ComfyUI/custom_nodes, then pip install -r requirements.txt and restart. It lives under the Danbooru/Style category.

First run is the rough edge: ~480 MB of downloads plus an HNSW index build that eats real RAM and time. Don't judge it by the first execution. One more heads-up from the source: the checkpoint loads via torch.load (pickle), which is a code-execution risk in theory - the repo only pulls from gustproof's official HuggingFace space, so it's a trusted-source situation, but that's why you shouldn't go copy random style checkpoints into the resource folder. And as with the rest of the pack, the index covers the whole board - matches can be explicit content, so keep the preview window expectations calibrated.