MSE Heatmap Tagger ๐
MSE Heatmap's cousin, working in the tagger's feature space
- features
- image
- IMAGE
This one's a genuine curiosity even by this pack's standards - filed under for_test like MSE Heatmap, but wired to WD-tagger's internal features instead of a pair of latents. Where MSE Heatmap diffs two latents directly, MSE Heatmap Tagger runs its comparison through the tagger's own learned feature representation, which is a meaningfully different question: not "where do these two images differ in pixel/latent terms" but "where does the tagger's internal read of this image show the most instability or sensitivity."
What it's built from
The input shape tells the story here. It doesn't take a latent1/latent2 pair like its sibling - it takes a single features value (WD-TAGGER-FEATURES, the same custom type the Grad-CAM nodes consume) plus the source image. That means the comparison isn't between two separate generations; it's something computed from the tagger's feature activations for one image, expressed as an MSE-style heatmap and composited back onto that same image. Think of it as a feature-space cousin to the Grad-CAM family in this pack rather than a direct extension of MSE Heatmap - same visualization style (heatmap over image, alpha-blended), different signal underneath.
Inputs and outputs
Required:
- features - a WD-TAGGER-FEATURES value, produced upstream by the pack's tagger feature-extraction node (in the same
wd-taggercategory, not covered in this batch - you'll need it feeding both this node and, typically, a Load Tagger somewhere upstream of that). - image - the source image the heatmap gets composited onto.
- alpha - overlay blend strength, 0-1, default 0.3.
Output is a single IMAGE.
Installing it
ComfyUI Manager, search "cgem156-ComfyUI", or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/laksjdjf/cgem156-ComfyUI
Restart ComfyUI afterward. No dedicated model download for this node - the tagger weights it depends on load back at Load Tagger.
The honest state of documentation here
This is about as deep into the pack's experimental corner as the node list gets, and it shows: there's no README section describing it, no tooltip text on any field, and essentially zero community discussion to cross-check against. That's worth knowing going in - this isn't a node with a settled, well-understood workflow behind it, it's a research artifact the author left in the repo. If you're the kind of person auditing WD-tagger's behavior for a dataset-quality project, it's worth experimenting with alongside the Grad-CAM nodes to see what it actually surfaces on your images; if you're looking for a reliable, documented diagnostic tool, MSE Heatmap (the latent-comparison version) and the Grad-CAM family are the better-understood starting points in this same folder.
Where to expect friction
The same wiring dependency as the rest of the wd-tagger tools applies: features isn't something you get directly from Load Tagger, it comes from a separate extraction step run over your image first. If this node errors on a missing or mismatched input, that upstream extraction node is almost certainly what's absent from your graph.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| features | WD-TAGGER-FEATURES | โ | |
| image | IMAGE | โ | |
| alpha | FLOAT | 0.300โ1 | โ |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | โ |