ImageComparer

You know the gesture: two images that are almost the same, and you drag a divider back and forth hunting for the difference. Whether a LoRA at 0.8 is doing anything. Whether the upscale added detail or just sharpening. Whether Checkpoint A or B has better hands. Doing it with two preview nodes side by side is guesswork; doing it with a slider is an actual judgement.

rgthree's Image Comparer is the well-known version of this node - it turns up in roughly a hundred corpus threads, and plenty of people say they use it on every workflow. Lany Nodes' ImageComparer is an independent implementation of the same idea, in the pack's own style: two inputs, no outputs, and a comparison surface in the browser.

How it works

Wire anything into image_a and image_b. Both are required IMAGE inputs. The node runs as an output node (it always executes, and the cache works backward from it), and it returns nothing to the graph - no output sockets at all. Instead it hands both batches to the frontend as UI payloads, and the pack's own JavaScript draws the comparison: a Slider mode that wipes between the two, a Click mode that flips between them, plus previous/next controls for walking a batch pair by pair, and right-click to download the resulting PNG.

The rule that trips people: the two batches must be nonempty and the same length. Corresponding images are compared one to one - image 1 of A against image 1 of B - so a four-image batch and a single image will just error out. Feed a batch into one side and a single image into the other and you'll get "requires image batches of equal length". Pad the short side into a matching batch, or compare two genuinely corresponding batches.

Dimensions, though, are allowed to differ. That's deliberate and useful, but read it as a warning rather than a feature: if the pair is a 1024×1024 original and a 2048×2048 upscale, the slider is comparing geometry as much as detail. For a fair A/B - two checkpoints, two LoRA weights, two samplers, same seed - keep the pair the same size so the only variable is the one you're testing.

The workflow it belongs in

The productive pattern is one seed, one prompt, two branches. Convert the sampler seed to an input, feed both branches from one Seed node so the noise matches exactly, change one thing on the B side, and compare. Any other approach and you're comparing two different random draws and calling it a model test.

This is also the node to reach for around a second pass. Because it accepts differing dimensions, it's the natural way to look at a base render against its upscaled version - and the right-click PNG download means you can grab the composite and post it without screenshotting your canvas.

Install

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/lany42/comfyui-lany-nodes.git
# restart ComfyUI

Manager: search comfyui-lany-nodes ("ComfyUI Lany Nodes"). No models, no extra dependencies beyond numpy and Pillow. Requirements are Python 3.13+ and ComfyUI's V3 node API, so a current install; on an older one the pack registers nothing and there's no ImageComparer in the Lany Nodes category.

One practical note, because this node is half frontend: the comparison surface is drawn by the pack's browser-side script, not by Python. If the node executes cleanly but renders as an inert box with no slider, the script didn't load - hard-refresh the tab (Ctrl-Shift-R) before assuming the node is broken, especially right after installing or updating the pack. The same class of frontend/extension friction is what badly disrupted the third-party organisation-node ecosystem through the Nodes 2.0 rewrite, where users' trusty comparers and reroutes broke overnight; the lesson there is that the more of your workflow rides on frontend extensions, the more a browser-side change can cost you.