Load Image Transceiver📡
Pull an image straight out of shared memory, no PNG decode involved
- seed
- channel
- image
LoadImageTransceiver is the "read" half of a two-node trick for passing images between processes on the same machine without ever touching disk. Its partner SaveImageTransceiver drops a tensor into shared memory under a channel name; this node pulls it back out and hands it to your graph as a normal IMAGE. If you're running one ComfyUI instance generating and another consuming frames in a loop, that's the whole point: no PNG encode, no file write, no input/ folder dance. Just memory.
Let's be honest about scope first. This is a tiny, single-commit, "UNDER CONSTRUCTION" pack from one author (nat-chan), and it shows 0 impressions on comfy.icu. Most people will never need it. You want it for a specific setup: two ComfyUI processes on the same host sharing an image stream at high throughput, where the classic SaveImage/LoadImage nodes are the IO bottleneck. Shared memory is per-operating-system, so this cannot cross machines, containers, or WSL boundaries. If your two processes can't see the same host's memory, this pack is dead on arrival.
How it works
The pack depends on the transceiver PyPI library, which wraps Python's multiprocessing.shared_memory. SaveImageTransceiver writes the tensor as a raw numpy buffer (plus a small metadata footer recording dtype and shape) into a block named transceiver-<channel>. LoadImageTransceiver opens that block by name, reconstructs the numpy array, and does torch.tensor(...) - a copy, not a view, so what you get is an ordinary ComfyUI IMAGE tensor (float32, 0–1, B,H,W,C) that plugs into anything a KSampler or VAE decode accepts.
That means wiring is trivial: it's a source node, so you can drag a link straight from its image output into your next node. There's also a channel string output - mostly a pass-through of what you typed, handy if you want to confirm which channel you read from.
The inputs that matter
channel(STRING, default"channel") - the only input you actually set. Must match the channel name on the Save side exactly, character for character. There's no discovery; get it wrong and you read nothing.seed(INT) - required but never used by the code. The frontend converts it into a seed-style widget, so it's effectively a "re-read now" bump: change it (or set control-after-generate to randomize) to force the node to re-execute. The number itself goes nowhere.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/nat-chan/comfyui-transceiver
cd comfyui-transceiver
pip install -r requirements.txt # installs the 'transceiver' library
Then restart ComfyUI. ComfyUI Manager can also install it if you search for "ComfyUI-Transceiver" - but the clone is the reliable route. There are no model files and no heavy dependencies; just Python 3.10+ and numpy/torch you already have.
Where people get burned
Two failure modes are baked into the library's source. First, ordering: read_numpy raises a RuntimeError (the channel name doesn't exist yet) if Load runs before Save has written. In one workflow that's fine - Save is upstream - but across two processes you need the writer to publish first. Second, stale blocks: writes use create=True and nothing ever calls unlink(), so a channel written earlier (even by a previous ComfyUI session) can still exist in the OS, and the next write to that same name fails. If you hit an "already exists" error, pick a fresh channel name or restart ComfyUI. There's also no locking, so two processes hammering one channel are racing. And ignore the /transceiver websocket route in the code - the read/write calls there are commented out and it returns dummy data. It's a stub, not a feature.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| channel | STRING | channel | — |
| seed | INT:seed | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| channel | STRING | — |
| image | IMAGE | — |