Shima MultiPipe 1.5 Out
The old-school pipe node that still rescues old workflows
- pipe
- pipe
- image
- mask
- latent
- model
- vae
- clip
- positive
- negative
- image_width
- image_height
- latent_width
- latent_height
Shima MultiPipe 1.5 Out is a legacy node, and it knows it. Before Shima invented its BNDL bundle system and the PCB-style Panels, this pack did what every other pack was doing in 2023: it shoved a dozen values into one PIPE_LINE wire and unpacked them at the other end. The Out side is the unpacker. It takes one pipe in and fans it out into 12 typed sockets, which is exactly what you want when an old workflow you just downloaded uses the Efficiency-style pipe pattern instead of Shima's newer BNDL stuff.
The honest use case: you found a workflow from the pipe era and it's full of MultiPipe In → MultiPipe Out pairs. This node is how you get at the contents. If you're building something fresh in Shima, the Panel system and the BNDL ecosystem replaced this whole pattern - the pack's own node reference calls the pipes "legacy." So reach for this when you're fixing an old graph, not when you're starting a new one.
How it works
Its partner, Shima.MultiPipeIn15, is the packer: it collects image, mask, latent, model, vae, clip, positive, negative, and four integer dimensions into a single tuple and hands it down one PIPE_LINE wire. This node is the exact mirror - it unpacks that tuple back into individual sockets. Under the hood that's literally all it does: the source is a plain Python tuple unpack.
One detail worth knowing: the Out node also passes the original pipe through as its first output, so you can chain it - unpack what you need at one point in the graph and keep the pipe flowing to a later node.
The inputs and outputs that matter
There's one input, pipe, and it's required. The outputs are the whole point:
pipe- the untouched PIPE_LINE, for chaining to another Out nodeimage,mask,latent,model,vae,clip- the actual payloadpositive,negative- the two conditioning slotsimage_width,image_height,latent_width,latent_height- four INT wires
Those four INT outputs are why this pattern exists: one node sets the dimensions once and every consumer reads the same values. Wire them into a latent maker or a resize node and you never type 512 twice.
How to install it
This is part of the Shima pack, so installing it installs a lot more than one node. Easiest is ComfyUI Manager - search "Shima" and install the KDB-USJP/shima_wf pack. Or, manually:
cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf.git Shima
Then restart ComfyUI. The pack's install.py will also clone two core dependencies you'll want for the wider ecosystem: ComfyUI-Impact-Pack and cg-use-everywhere (Shima's whole "islands auto-connect" thing is built on Use Everywhere). Its requirements.txt is just aiohttp and requests - most of what the pack needs already ships with ComfyUI.
Common issues & troubleshooting
"not enough values to unpack" on execution. The XL and 1.5 pipes are different shapes. MultiPipeOut15 expects the 12-field SD1.5 tuple; feed it an XL pipe (which carries an sdxl_tuple and a refiner block) and the unpack fails because the lengths don't match. Check which In node made the pipe.
The pipe type isn't cross-pack compatible. PIPE_LINE is a convention, not a standard. A pipe from Efficiency Nodes or Easy-Use is a dict with its own key names; Shima's is a plain tuple. If you feed a foreign pipe in, the outputs come back wrong or the node throws. Match Shima's In to Shima's Out.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| pipe | PIPE_LINE | — |
Outputs (13)
| Name | Type | Description |
|---|---|---|
| pipe | PIPE_LINE | — |
| image | IMAGE | — |
| mask | MASK | — |
| latent | LATENT | — |
| model | MODEL | — |
| vae | VAE | — |
| clip | CLIP | — |
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| image_width | INT | — |
| image_height | INT | — |
| latent_width | INT | — |
| latent_height | INT | — |