LC Fingerprint Identify 🔎

What this is for

You downloaded something called Krea2_UltraReal_V6_NSFW.safetensors with no model card. Is it a finetune? A merge of Turbo and somebody's realism checkpoint? Does it have a face-lock LoRA baked in? Normally the answer is "run it and guess", which is a terrible way to find out.

LC Fingerprint Identify 🔎 tries to answer it from the weights. Point it at files or folders and it writes, in plain words, what each one is made of: which models in your library were merged, at what ratio, which blocks came from which parent, which LoRAs went in and at roughly what strength, and how much of the file it simply can't explain. It's an output node with two sockets - a report string and a heatmap image - so it runs without wiring anything downstream.

The honest headline first: it can only name ingredients that are in your library. It isn't an internet lookup. Build the library with LC Fingerprint Library 📚 first, and make sure the parents live in it.

The mechanism, briefly

A merge is arithmetic, and arithmetic is reversible if you kept the operands. For each block of the model, the node fits the mystery weights as a non-negative mix of your library models that adds up to 1 - i.e. a merge ratio - with library LoRAs layered on top at per-LoRA strengths that stay constant across blocks. Whatever the fit can't account for is reported as "not in the library": either the maker's own training or an ingredient you don't have. On a file built from scratch, that leftover is usually most of the answer.

Confidence per ingredient comes from how much worse the fit gets without it, so a model another one can stand in for scores low - the right instinct. The overall likelihood is the share of the change explained multiplied by how sure it is of the weakest named ingredient. The family's reference base is picked automatically (for Krea 2 that's Turbo, since most finetunes start from it).

A LoRA gets handled differently: it's matched against the library's LoRAs by similarity of the change itself, so a renamed copy still shows up, and a 0.98+ match is reported as "it is this LoRA, or a copy of it."

Inputs and outputs

files is the whole node. One entry per line, and it takes full paths, paths relative to the ComfyUI folder, or a registered folder name like diffusion_models - so you can point it at a folder of downloads in one line.

recursive is off by default here, unlike the library node. A folder gets its own files and stops. If your downloads are sorted into subfolders, flip it.

add_to_library is off by default and worth turning on for anything you plan to keep - the file goes into the library as it's identified, so next time it's a known quantity.

Outputs: report (the text answer, also printed to the console) and heatmap, one image per model, batched and padded to the largest - send it to Preview Image or you'll never see it. Rows are blocks, columns are the library models, the LoRAs, and a red "not in library" column; brighter means a bigger share. A block merge looks like a hard colour change down a column. A plain weighted merge looks like a flat wash.

Install

ComfyUI Manager → search LC Modelbuilder. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/lonecatone23/ComfyUI_LC_ModelBuilder_nodes

Restart, then hard-refresh the browser (Ctrl+Shift+R). There's no requirements.txt - this node needs only torch, numpy and PIL, which ComfyUI already has. install.py is for the face scorer's onnxruntime and has nothing to do with fingerprints. If the node doesn't appear, check that __init__.py sits directly in custom_nodes/ComfyUI_LC_ModelBuilder_nodes/ and not one level deeper; the author warns about that nested-folder case in the console.

Where it bites

An empty or thin library. With no models of that family you get "No Krea 2 models in the library yet to compare with" and nothing else, and with only one parent in there, everything looks like that parent. The tool is exactly as good as what you fed it.

Low-precision files blur the answer. Rounding in an fp8 or lower file is roughly the size of the differences between sibling finetunes, so the node may tell you it can't read a recipe at all and to try a bf16, fp16 or fp8 copy. Take that at face value.

GGUF is out. Only .safetensors files are picked up, so a .gguf in your download folder is silently ignored - no error, just not in the report.

Unknown architectures aren't guessed at. Something the family detection doesn't recognise comes back as "not an image or video model the library knows", and a LoRA in a format it can't decompose (Tucker, conv-only) is skipped with a note.

It's an explanation, not a receipt. "Very likely (72%)" is a good reason to trust your eyes about whether a checkpoint is a rebrand of something else - not proof. The leftover percentage is where the interesting ambiguity lives.