Kaloscope Image Analysis

Image Analysis is Feature Analysis with the extraction step folded in. Instead of handing it a ready-made tensor, you give it images plus a loaded model, and it does the whole chain in one node: preprocess, run the backbone, compute distances, cluster, draw. If you want one node to tell you what's going on in a folder of images, this is the shortest path to it.

It also has one output its sibling doesn't: features. So it isn't only the lazy option - it's the node you use when you want a chart now and the vectors later. Extract once inside this node, then pipe features into additional Feature Analysis nodes for the other seventeen chart types without paying for inference again.

How it works

The node's schema is literally built from the other two: it takes Feature Analysis's inputs and prepends image and model, and it takes Extract Features' optionals (output_type, layers, intermediate_norm) so it can do the extraction itself. It runs the extractor, then hands the tensor to the same CPU analysis engine as Feature Analysis, along with your images as thumbnails for the charts that draw them.

The clever bit is layout inference: if tensor_layout is auto, this node fills it in from output_type - patch_map becomes spatial, intermediate outputs become layer_vectors, layer_tokens or layer_spatial as appropriate - so you don't have to hand-match layout to output type the way you do when passing a raw tensor into Feature Analysis. Note that this only helps when this node did the extraction; the layout rules still apply to whatever it emits.

Where it differs in the fine print: Feature Analysis has an optional images input for thumbnails, and this node removes it, because your images already are the input. Everything else - metric, normalize, cluster_method, n_clusters, top_k, reference_index, labels, seed, perplexity, dbscan_eps, dbscan_min_samples, max_dimensions, heatmap_order, grid_width, width, height, layer_index, layer_pooling, token_pooling - behaves identically. Same eighteen chart types, same 512-image ceiling, same refuse-to-guess rule for 4-D tensors when you've set tensor_layout yourself.

Outputs

visualization is the chart as an IMAGE, ready for Preview or Save. analysis_json holds the numbers behind it. features is the extracted tensor - the interesting one, because it makes this node a hub rather than a dead end. distance_matrix is the [B,B] pairwise tensor.

An honest caveat about the last two: on a big batch, features for patch_tokens output is a lot of float32 to hold in memory, and the pack caps analysis at 512 images precisely to avoid that getting silly. For global-vector work - default, cls, cls_mean - it's small and you can wire it into as many downstream nodes as you like.

Install

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

Weights and config.json go in ComfyUI/models/kaloscope/<folder>/; Kaloscope v2 with a ModelScope mirror is what's downloadable today, and v3 DINOv3 models are still unreleased. On Windows the pack also installs triton-windows, which the LSNet attention kernel requires - skip it and you get an import error, not a slowdown.

Which one should you use?

If your graph already extracts features - because you're also feeding Clustering or a comparison node - use Feature Analysis and share the tensor. If you're exploring, use this one: image batch in, picture out, no intermediate wiring, and features on the side for whatever you think of next.

The practical snag either way is batching. ComfyUI needs uniform sizes within a batch, so a mixed-resolution reference folder must be resized or padded first, and higher resolution buys you nothing since the backbone resizes to its own training size anyway. Also keep the model config fixed for a comparison: these charts show the geometry of one embedding space, and mixing checkpoints across branches gives you two charts that look comparable and aren't.