Slimy_ImageComparer
Slide between two generations and actually see what changed
- image_A
- image_B
- images
You know the drill: fix the seed, change one thing, re-run, and now you have two images that look almost identical and you cannot tell which one you like better because they're sitting in different corners of the graph. Slimy_ImageComparer is a tiny terminal node that lets you flip between two images - or slide a divider across them - right in the canvas, so the difference actually shows. It's the A/B comparison habit made concrete: change one variable, compare, keep the winner.
The obvious alternative is rgthree's Image Comparer, which most people already own, and this node is honest about its lineage - the README says it's rgthree's code, reworked. So why a standalone? Because rgthree's comparer was one of the nodes that broke in ComfyUI's Nodes 2.0 frontend rewrite, and a comparer that draws its own UI and ships as a single Python file plus one JS file doesn't drag the whole quality-of-life pack along. You also get two things rgthree's doesn't print: each image's resolution, and color-coded A/B labels so you never lose track of which side is which.
How it works
The backend is a thin subclass of ComfyUI's built-in PreviewImage. When the queue runs, it hands each incoming image to ComfyUI's normal save machinery (files land in the temp folder with a slimy.compare. prefix) and streams them back to the frontend. All the actual comparing is client-side: the web/slimy_image_comparer.js file renders the node body, the mode buttons, and the slider. Nothing here calls out to an API, needs a key, or requires a single pip install - this is pure frontend sugar over a stock preview node.
The inputs that matter
image_Aandimage_B- both optional IMAGE tensors, so you can wire one or both. In practice you'll take the outputs of your twoVAEDecodenodes and feed them in.
That's the whole input list. The node declares an images IMAGE output on the schema, but treat this as a terminal - it's an output node by design, and nothing useful comes out of that port. Put it at the end of a branch and look at it.
Once it's run, the node body shows three clickable buttons:
- A - image A only
- B - image B only
- Slide - a draggable divider with A on the left, B on the right (this is the default, and the one you'll use)
Hover over the image and the split follows your cursor. The colored top and bottom bars show A: 1024×1024 / B: 1024×1024 so you can spot at a glance when your two generations aren't even the same resolution. Right-click the node and you get open-in-new-tab, copy, and save for whichever image is showing.
Installing it
ComfyUI Manager can find it if you search "Slimy_ImageComparer", or do it by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/Slimy-Comfy/Slimy_ImageComparer
Restart ComfyUI and the node appears under the Slimy category in the add-node menu. No model downloads, no extra dependencies - the whole thing is one Python file and one JS file.
Where people get confused
The preview only refreshes when the queue actually runs, so plugging in new images and staring at the node won't do anything until you hit the run button. And the mode (A/B/Slide) is stored on the node and saved with the workflow - which is convenient, but means you'll occasionally open an old workflow and find it stuck in "A" mode. Click the bar to switch back. If the node shows nothing at all after a run, check that you wired image_A/image_B rather than, say, a latent - it only accepts decoded IMAGE tensors. Beyond that it's about as low-friction a node as ComfyUI has: a comparer with zero setup, for the one habit that actually makes your prompt tweaks measurable.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| image_Aopt | IMAGE | — | |
| image_Bopt | IMAGE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |