Nodes/Shima/Shima MultiPipe 1.5 In
ComfyUI Node

Shima MultiPipe 1.5 In

Stuff your whole SD1.5 pipeline down one pipe

By KDB-USJP·Created 6 months ago·Updated 6 months ago· 2
Shima MultiPipe 1.5 In
  • image
  • mask
  • latent
  • model
  • vae
  • clip
  • positive
  • negative
  • pipe
image_width512
image_height512
latent_width512
latent_height512

Shima MultiPipe 1.5 In is a packing node: it takes the eight main signals of an SD1.5 pipeline - image, mask, latent, model, vae, clip, positive, negative - plus four dimension values, and bundles them into a single PIPE_LINE output. One wire in, one wire out, and the whole generation payload travels as a unit. It's the same idea as rgthree's Context nodes and the classic "pipe" pattern: fewer wires crossing the canvas, one tidy bundle instead of a spaghetti tangle.

Why SD1.5-flavored? Because this variant's dimension defaults are 512 (both image and latent width/height), which is the resolution SD1.5 checkpoints expect. It's a hint about what you're building for, not a hard rule - the values are editable.

The mechanism

execute just assembles a tuple in a fixed order: (image, mask, latent, model, vae, clip, positive, negative, image_width, image_height, latent_width, latent_height). That ordering matters because the matching output side - the pack's MultiPipeOut15 - unpacks the pipe by position, not by name. Every input is optional, so you can pack a partial pipeline; the gaps become zeros/None in the pipe. To unpack the pipe at the far end of the island, you'll want the companion out node, which splits it back into individual typed sockets.

The inputs that matter

  • The eight signal sockets (image, mask, latent, model, vae, clip, positive, negative) - wire in whatever your pipeline has.
  • image_width / image_height / latent_width / latent_height - the dimensions, defaulting to 512/512 each. These ride along in the pipe so the consuming side knows the target size without you re-typing it. Note they're INT inputs with a huge max; keep them sane multiples of 8.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf

then restart, or ComfyUI Manager → search "Shima". No models, no extra dependencies.

The honest take

The pipe pattern is genuinely useful - it's how you keep a big workflow readable, and the KB's plumbing doc is basically a love letter to the "bundle of connections down one wire" idea. But be warned: this is a Shima-proprietary PIPE_LINE type, so a Shima pipe only unpacks with a Shima node (or a compatible one that knows the same tuple layout). That's a lock-in worth knowing before you build your whole template on it. Also, the exact tuple order is the contract - if you hand this pipe to a node expecting a different layout, you'll get silent garbage, not an error. And honestly, for the pure bundling job, rgthree's Context or any of the well-trodden pipe packs do the same thing with a bigger ecosystem of unpackers; MultiPipe In 15 earns its place if you're already living inside Shima and want its defaults, not as the reason to install the pack.

CategoryShima/Routing

Inputs (12)

NameTypeDefaultDescription
imageoptIMAGE
maskoptMASK
latentoptLATENT
modeloptMODEL
vaeoptVAE
clipoptCLIP
positiveoptCONDITIONING
negativeoptCONDITIONING
image_widthoptINT51264–18446744073709550000
image_heightoptINT51264–18446744073709550000
latent_widthoptINT51264–18446744073709550000
latent_heightoptINT51264–18446744073709550000

Outputs (1)

NameTypeDescription
pipePIPE_LINE