Nodes/ComfyUI-Jumper/Receive Images
ComfyUI Node

Receive Images

The other half of the wire, where the pictures come back home

By myonmu0·Created 11 months ago·Updated 9 months ago· 0
Receive Images
    • images
    • order
    addr127.0.0.1:8282
    modeClient
    order0

    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, default 127.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 order output, 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.

    CategoryJumper

    Inputs (3)

    NameTypeDefaultDescription
    addrSTRING127.0.0.1:8282
    modeCOMBOClient2 options: Client, Server
    orderoptINT0

    Outputs (2)

    NameTypeDescription
    imagesIMAGE
    orderINT