Images Masks MultiPipe (JPS)

Most of this pack's "Pipe" nodes bundle values into a single opaque BASIC_PIPE wire and unpack them elsewhere - great for numbers, awkward for images and masks, which are heavier objects you'd rather see clearly on the canvas than hide inside a tuple. This node takes the opposite approach, and the README says as much directly: it's a pipe built to "access/change images and masks more easily than classic 'from/to/edit'-pipes." Nine slots, each keeping its own native type (IMAGE, MASK, or MODEL), all optional on both the input and output side.

What it actually does

Every input mirrors an output of the same name: generation_img / generation_mask, ipa1_img / ipa1_mask, ipa2_img / ipa2_mask, revision1_img, revision2_img, and inpaint_model. Whatever you plug into an input comes back out the matching output, unchanged. It's a junction box - a single node you place at a strategic point in a large graph to gather scattered image, mask, and model wires, then re-tap any of them downstream without redrawing long connections across the whole canvas every time you rearrange nodes.

The slot names tell you what workflow this is built for: a main generation image and mask, up to two IP-Adapter reference images with their own masks, up to two Revision reference images, and a dedicated inpainting model slot for workflows that swap in a specialized inpaint checkpoint. That's a lot of simultaneous image inputs for one pipeline - consistent with the README's older description of a "IP Adapter Settings" node that toggled five reference images on and off. The numeric weight/crop/mask-mode tuning for those adapters now lives in separate nodes (IP Adapter Settings (JPS) and friends); this node is specifically where the actual pixel data travels.

You don't have to wire all nine. Connect only the slots your workflow actually uses and leave the rest empty - an unconnected optional input just passes through as nothing, and nothing downstream is forced to consume an output it doesn't need.

Installing it

ComfyUI Manager, search JPS Custom Nodes for ComfyUI, or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/JPS-GER/ComfyUI_JPS-Nodes.git

Restart ComfyUI, and remove any earlier copy of the pack first - the README calls this out explicitly. Pure routing node, no models of its own; whatever you feed it (a checkpoint for inpaint_model, images from wherever they're loaded) is something you're sourcing elsewhere.

Where people get tripped up

This node doesn't process, combine, or validate anything - it's not doing masking math or blending images together, purely relaying whatever's connected. If an output looks wrong, the bug is almost certainly upstream of this node, not in it.

The other thing worth knowing: because every slot is optional on both sides, it's easy to accidentally leave a slot disconnected on the input side while something downstream still expects that output to carry real data - ComfyUI won't necessarily flag this until the workflow actually runs and hits a node that needed an image it never got. Double-check the specific slots your active branch depends on are wired all the way through, especially in a big workflow where this node sits in the middle of a long chain and it's easy to lose track of which of the nine pairs are actually load-bearing for the run you're about to queue.