Image Searcher

This is the node the whole pack is built around. Image Searcher takes an embedding of one image (or one text prompt, via the Cond2Embeds trick) and scores every image in a pre-built database against it, from "identical" to "why did you even ask". If you've ever wanted to dump 50,000 reference images in a folder and say "find me everything that looks like this photo," this is your node.

It's not a classifier and it's not magic. It's a cosine-similarity lookup, and knowing that saves you a lot of frustration about what it can and can't do.

How it works

Your database (built by GenerateDB) is a JSON file holding one CLIP vision embedding vector per image. When you run Image Searcher it flattens your query embedding, stacks all the stored vectors into one numpy array, and computes cosine similarity for every entry at once: dot_products / (image_norm * feature_norms). That's a single matrix-vector product, which is why even a collection of ~100,000 images - the size the author says he's tested - scores in well under a second once the DB is loaded.

Two things worth knowing about the output. First, the results come out unsorted. The Result Browser nodes downstream do the ranking; this node just hands you the raw scores plus the stored features. Second, the SRESULTS output is a custom type that only this pack's sibling nodes understand - ImageSearcher → ResultBrowser/ResultBrowserAdvanced, and the ResultCombiner/ResultSubtract/EditResults/FolderScores chain. You can't plug it into anything else, and none of it works if you lose the DB pairing.

The inputs that matter

Only two, and both are obvious wires rather than settings:

• img_db - the LoadDB output. If this isn't connected, nothing happens.
• clip_vision_output - from a core CLIP Vision Encode node (load an image, wire it through "Load CLIP Vision" → "CLIP Vision Encode").

The README's rule number one: every database you chain must be generated with the same CLIP vision model, and your query should come from that model too. Mixing a bigG-14 database with a ViT-H query is where people get burned first. The author recommends CLIP-ViT-bigG-14-laion2B-39B-b160k, which is the same vision encoder IP-Adapter uses for SDXL - decent odds it's already sitting in your models/clip_vision folder.

Installing it

From ComfyUI Manager, search "ClipVision_Tools" and install. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/MoonMoon82/ClipVision_Tools
cd ClipVision_Tools
python -m pip install -r requirements.txt

Restart ComfyUI. Dependencies are light - just orjson and pillow-heif - so there's no dependency hell here. The one heavy download is the CLIP vision model itself into ComfyUI/models/clip_vision.

Common issues

• "shape mismatch" / nonsense results: query encoder doesn't match the DB model. Re-encode with the same CLIP vision model that built the DB.
• Every score comes out 1.0 or 0.0: usually a text/vision mismatch - see Cond2Embeds for the shape-check.
• File not found when you open a result: the DB stores relative paths and LoadDB re-joins them to your path_to_images_folder. Move the images and everything breaks; fix paths with EditResults' "replace" or regenerate.
• No reddit footprint: this is a small community pack (MIT, based on PnthrLeo's PL-data-tools), so when something's wrong you're mostly debugging from the README and the source. The source is small and readable, which is a blessing.