Receive Images
The other half of the wire, where the pictures come back home
- images
- order
Every Send Images needs a Receive Images on the other end - this is it. If you've got a cloud GPU box doing the heavy sampling while your local ComfyUI stays as the control surface, Receive Images is the node that catches the result when the remote machine throws it back. Same pack, same raw-socket transport, opposite direction.
How it works
Receive Images reads a stream from the socket and reverses whatever the sending side did. The payload carries its own format tag, so the receiver adapts: if the sender chose png, the bytes come back as a batch of PNGs that get decoded into an IMAGE tensor; if they chose zlib or raw, it's a safetensors file that loads straight back to tensors. Either way you get a normal ComfyUI IMAGE you can plug into anything.
The handshake matters more here than on the sending side. The receive path starts by reading a size prefix, then streams the data in 4KB chunks while a progress bar ticks up, then verifies the SHA-256 hash baked in by the sender. If the bytes got mangled mid-flight you'll see a Hash don't match. exception rather than a corrupted image, which is the right failure mode. If the other side sent something that isn't an image at all - say a Send String got pointed at your Receive Images - you get Receive unexpected data. That's your cue that the chain on one side doesn't line up with the chain on the other.
The inputs and outputs
Only three inputs, and two of them are the boring setup:
- addr -
host:port, default127.0.0.1:8282. Must match what the Send Images node on the other machine is using. - mode - Client or Server. Mirror the role: if Send Images is a Client, Receive Images should be a Server, and vice versa. The README's standard layout is Client on local, Server on remote, with the SSH tunnel connecting them.
- order - chain this from the previous Jumper node's
orderoutput, same chain both sides.
The outputs are the payoff: images (an IMAGE batch, wire it into PreviewImage, SaveImage, or straight into img2img, IP-Adapter, ControlNet preprocessors) and order, which you pass on to the next Jumper node or anchor into a PreviewAny so the chain runs.
One tip from the source: because the receiver rebuilds the tensor batch from what came over the wire, the lossy-ness is decided by the sender's send_as choice, not yours. If you're receiving for a precision-sensitive stage (re-encoding, control conditioning), ask whoever's running the Send side to use zlib or raw; if it's just for eyeballing, png is smaller and faster.
Installing it
No dependencies, no model downloads - this pack is pure Python plus what ComfyUI already ships (torch, PIL, safetensors, zlib). Install through ComfyUI Manager by searching ComfyUI-Jumper, or:
cd ComfyUI/custom_nodes/
git clone https://github.com/myonmu0/ComfyUI-Jumper
Then restart ComfyUI.
Where people get burned
The two classic failures: a hash mismatch when data is corrupted in transit (rerun or check your tunnel), and a mode mismatch where both sides try to be Clients or both Servers - one side waits forever to connect. Remember that cancel doesn't work while a Jumper node is mid-flight, so restart ComfyUI to abort. And for anything over the internet, the author's warning stands: use an SSH tunnel, because this is plain unencrypted TCP. Community PSA history in the ComfyUI ecosystem makes the same point about exposing an unauthenticated instance - the tunnel is non-negotiable.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| addr | STRING | 127.0.0.1:8282 | — |
| mode | COMBO | Client | 2 options: Client, Server |
| orderopt | INT | 0 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| order | INT | — |