LatentReceiver
Pull a latent back out of a thumbnail image, matched by link_id
- LATENT
This one has a genuinely clever mechanism underneath it, so it's worth explaining rather than just listing the inputs. LatentReceiver is paired with LatentSender - set both to the same link_id and the latent produced by the sender arrives at the receiver. What makes it interesting is how: per the README, LatentSender is built on top of the pack's PreviewLatent machinery, which encodes the actual latent tensor into the payload of a PNG thumbnail - the little preview image gets the real data smuggled into it. LatentReceiver reads that thumbnail back and decodes the latent out.
Why go through an image at all
Because that's what makes it work across separate runs, not just within one. A normal wire only carries data within a single graph execution. Saving the latent as a physical file - even one disguised as a preview thumbnail - means it survives after the run ends and can be picked up later: from a different part of the UI, a separate workflow tab, or a subsequent execution that doesn't re-run everything upstream. It's a checkpoint you can come back to, not just a same-pass connection.
The inputs and output
latent- an enum-style picker of available saved latent thumbnails (populated once you've actually run a matchingLatentSender; empty if nothing's been sent yet in your environment - a first-run chicken-and-egg step you just have to get past once).link_id(default 0) - the pairing key. Must match theLatentSenderyou want to pull from.trigger_always(defaultfalse) - ComfyUI normally skips re-running a node if none of its own widget values have changed since last time. Since this node's job is to notice externally delivered data that its own widgets don't reflect, enabling this makes sense if you want it to check for a fresh latent every run rather than risk being cached and skipped even though the sender delivered something new.
Output is a single LATENT, decoded back from the thumbnail payload.
The thumbnail-quality footnote
The README calls this out directly and it's worth repeating so you don't panic over it: because ComfyUI's current structure can't distinguish an SDXL latent from an SD1.5/SD2.1 one at the preview stage, LatentSender always decodes the preview thumbnail using the SD1.5 method - regardless of what model actually produced the latent. If you're working in SDXL, the little preview image can look a bit off. That's cosmetic only. The actual latent tensor transferred through the payload is the real one; only the thumbnail's own appearance is approximated.
Installing it
Bundled with the pack, no separate step. Via ComfyUI Manager: search ComfyUI Impact Pack, Install, restart. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack
cd ComfyUI-Impact-Pack
pip install -r requirements.txt
(portable: python_embeded\python.exe -m pip install -r requirements.txt), restart. No models needed.
Common issues
Dropdown is empty or nothing arrives. Run the matching LatentSender at least once first - the picker only lists thumbnails that actually exist on disk. Also double-check link_id matches on both ends.
Works locally but not across machines/instances. The mechanism depends on the receiving ComfyUI being able to see the same output/temp location the sender wrote its thumbnail to. Two separate machines or containers with no shared storage won't be able to hand a latent off this way.
Preview thumbnail looks wrong on SDXL. Expected, per the README's own caveat above - it's the preview decode, not the actual data. Don't chase it as a bug.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| latent | COMBO | 0 options: | |
| link_id | INT | 00–9223372036854776000 | — |
| trigger_always | BOOLEAN | false | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| LATENT | LATENT | — |