Nodes/c4f-wire-loom/Loom Latent Out
ComfyUI Node

Loom Latent Out

Read the latent back at each stage of the pipeline

By Codes4Fun·Created 3 months ago·Updated about a month ago· 0
Loom Latent Out
  • loom
  • LOOM
  • LATENT
  • exists
label

Multi-stage sampling needs to read the working latent at every stage, and Loom Latent Out is the node that does it - it pulls the LATENT back out of the loom stream, passes it to a sampler, and lets the loom continue to the next stage.

Why you'd reach for it

Think of an edit pipeline: encode once, sample, refine, upscale. Each stage begins with Loom Latent Out pulling out the current latent, and if the stage produces a new one, a Loom Latent In (same label) pushes it back in. Because the loom is a stream, each subsequent stage reads the latest latent - the "take it out, modify it, put it back" loop that c4f-wire-loom is built around.

It's also the branching tool: push a latent into the loom through Loom Split, and several parallel Loom Latent Out nodes each read their own copy for side-by-side comparisons or different sampler settings. Reads don't consume, so they all see the same starting latent.

How it works

Standard loom lookup:

key = f"LATENT_{label}" if label else "LATENT"
if key not in loom:
    return (loom, None, False)
return (loom, loom[key], loom[key] != None)

The latent stays in the loom after reading, so you can read it at stage one, stage two, and stage three without re-inserting.

The outputs that matter

  • LATENT: the latent under that label, or None if absent.
  • exists (BOOLEAN): True when the key exists. Genuinely useful here - a latent edit pipeline that reads None halfway through produces garbage or errors, and exists tells you which stage lost the stream.
  • LOOM: the loom, passed through unchanged.

Inputs are loom (LOOM, required) and label (string), matching the Loom Latent In that stored it.

Installing

Part of c4f-wire-loom. ComfyUI Manager → search "c4f-wire-loom" → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Codes4Fun/c4f-wire-loom

No extra deps, no downloads.

Where it bites

The stream-order trap is the big one for latents. If stage two pushes its output back into the loom but stage three's Loom Latent Out is wired to an earlier point in the stream, stage three reads the old latent. Keep the loom flowing forward in execution order and you're fine. And shape mismatches bite: a latent resized by a stage won't match the sampler config downstream, which is a schedule/size error, not a loom bug. Nodes 2.0's arrow-drag collapse quirk applies pack-wide, with the workaround shipped.

Categoryutils/route

Inputs (2)

NameTypeDefaultDescription
loomLOOM
labeloptSTRING

Outputs (3)

NameTypeDescription
LOOMLOOM
LATENTLATENT
existsBOOLEAN