Combine Results

Combine Results takes two SRESULTS sets and merges them into one by keeping the lower of the two scores for each position. It's the pack's "intersection-ish" node: run two different query images against the same database, combine, and images that matched either query stay high while images that only matched one get pushed down. The result set then feeds the normal browsers like any single search.

Mechanically it's dead simple - element-wise minimum of the two distance arrays, keeping the first result set's feature list. Two inputs (results1, results2), one output (RESULTS), no settings. You'll use it when "similar to A or B" is a query you want to rank by the better match.

The catch that matters

The combine is done by position, not by filename. It assumes both inputs are results from the same database in the same order - which is true when both came from searches against the same LoadDB output, and false otherwise. Feed it results from two different databases and you're min-ing together scores for different images, which produces a plausible-looking but meaningless ranking. This is the classic silent-failure mode: no error, just wrong results.

The practical rule: one LoadDB feeding both searches. Wire the same IMG_DB into two Image Searchers, give each a different query (say, two reference images), then combine. That's the intended pattern and it works cleanly.

Installing it

Standard pack install:

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

Or ComfyUI Manager → "ClipVision_Tools" → restart. Deps are just orjson and pillow-heif.

Gotchas

• Same-DB rule (above) is the whole thing. Different DBs, or chained DBs in different orders, and the merge is garbage.
• It's min, not an average - an image that's a great match for query A but terrible for query B keeps query A's high score. That's the "or" semantics; if you want "similar to both," that's a different operation (element-wise max or an average - not what this node does).
• Scores stay raw: there's no re-ranking after the min, so the combined list isn't sorted until it hits a browser node. That's fine, just don't expect the output order to be meaningful by itself.

For its narrow job - "rank by the best of two queries" - it's genuinely handy, and it's one of the few ways to get multi-query search out of this pack without the experimental embedding math. Just keep both inputs on the same database and it'll behave.