Image Pair Split

A small utility with a single job: take one IMAGE that's actually a batch of two images stacked together, and split it back into two separate outputs. If something upstream in your graph produced or loaded a pair as one batched tensor - which happens fairly often in RES4LYF's dual-guide workflows, where the README shows setups using two reference images together, like a composition guide and a style guide, or two masked inputs for unsampling - this is how you get them back apart to feed two different destinations.

There's no processing here beyond the split itself. No resizing, no color adjustment, nothing - it's purely bookkeeping so a paired batch that traveled through one wire can go back to being two separate images for two separate downstream nodes.

Inputs and output

• img_pair (IMAGE) - required. A batch of exactly two images.
• Outputs: img_0 and img_1 (IMAGE) - the two images, split apart.

Which image ends up as img_0 versus img_1 depends entirely on the order they were batched in upstream - the node isn't doing anything clever to sort them, it's just unpacking the batch in the order it received it.

Installing it

Comes with the full RES4LYF pack:

• ComfyUI Manager - search "RES4LYF," install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/ClownsharkBatwing/RES4LYF, then cd RES4LYF && pip install -r requirements.txt, restart.

Nothing else to download for this one.

Common issues

img_0 and img_1 came out swapped from what you expected. Since the split order just mirrors the batch order, trace back to wherever the pair was assembled and check which image went in first. If you built the pair yourself with an image-batching node, that's the place to fix the order rather than trying to compensate downstream.

Only one image, or more than two, came in. This node expects exactly a pair. If img_pair only carries a single image, or carries more than two, behavior isn't documented by the pack - the safest assumption is that it won't do what you want, so check your batch size before this node rather than after.

Not sure why you'd need this over just loading two separate images. If nothing upstream is genuinely producing a batched pair, you probably don't need this node at all - just wire your two images independently. It earns its place specifically when something else in the chain (a loader, a paired-guide node, or your own batching setup) hands you one combined image and you need it apart again.