Kaloscope Artist Similarity

You've got a folder of references in a style you like - the artist's actual gallery, or your own best renders - and a new image just came out of the sampler. Is it close? Kaloscope Artist Similarity gives you a number for that. One query image against a whole batch of references, cosine similarity for each, all in a single JSON string.

This is the node that turns "this feels like it's drifting" into evidence. It's also the cheapest way to sanity-check a style LoRA: run a few of your LoRA outputs against a handful of real works by the artist (the targets) and a handful of outputs from the base checkpoint (the controls). If your LoRA outputs don't score higher against the targets than the controls do, the LoRA isn't doing what you think.

How it works

Both sides of the comparison go through the same path: the loaded Kaloscope model with return_features=True. The node grabs the first image from each input, converts the 0–1 float tensor back to PIL, applies the checkpoint's training transform, and runs the backbone to get one vector per image. Then it's plain dot-product math - dot(a, b) / (|a| * |b|) - which for unit-normalized features is the cosine similarity you'd expect: 1.0 means identical direction, 0 means unrelated, negative means actively opposite.

Note what that means in practice: this node compares pooled global features only. If you want to compare patch-level or intermediate-layer features, or compare group averages instead of individual images, the Feature Analysis side of the pack does that. Here it's one vector per image, and the reference batch is walked image by image.

Inputs and output

processed_image is your query - the name suggests it's meant to come after whatever you did to the image (upscale, crop, a finished render), because preprocessing inside the node is only the model's own resize/normalize. reference_images is an IMAGE batch; every frame in it gets scored. model is the bundle from the loader.

The output is a single similarity_json string holding three things: processed_features, reference_features, and similarities - a list of floats in reference-batch order. Parse it with a JSON node or rgthree's display, or just read it in the node's text output. There's no IMAGE output and no label output; if you want a picture you're in the wrong node.

If your query image is also inside the reference batch, expect one score of exactly 1.0. That's not a bug - it's the same vector against itself, and it's a handy way to confirm the pipeline is wired correctly.

Install and wiring

cd ComfyUI/custom_nodes
git clone https://github.com/spawner1145/comfyui-kaloscope
cd comfyui-kaloscope
python -m pip install -r requirements.txt

Weights go in ComfyUI/models/kaloscope/<folder>/ with config.json beside them - Kaloscope v1/v2 are the public ones; v3 isn't out yet. Restart after dropping a new folder in, then Kaloscope Model Loader → both inputs here.

Where people get burned

Batching. reference_images is a normal ComfyUI IMAGE batch, and ComfyUI requires every image in a batch to be the same size - so a folder of mixed-resolution references needs a resize/uniform-size step before it reaches this node. Mixing sizes doesn't average out; it errors or gives you garbage.

Second: similarity scores are only meaningful inside one model and one feature configuration. A v2 LSNet checkpoint and a DINOv3 checkpoint live in different embedding spaces, so cross-model numbers mean nothing. Even the same checkpoint with a different pooling setting (feature_source in config.json) shifts the scale. Keep one model per experiment.

Third, and the one that bites on real workflows: these backbones see a resized, center-cropped version of your image at the checkpoint's training resolution. If a style lives in fine line work or a signature-esque texture, it survives the resize poorly, and two visually distinct pieces can both land near 0.8. Read similarity as a relative ranking among your own images, not as an absolute "this is 80% the same".