Send Image with Dimensions GIMP (WebSocket)
The GIMP round-trip, now with dimensions attached
- images
The smarter sibling of Send Image GIMP (WebSocket) - same job, one crucial addition. Send Image with Dimensions GIMP (WebSocket) takes an IMAGE at the end of your graph and sends it back to GIMP, but this time the message tells the receiver how big the image is before the pixel data arrives.
That detail matters more than it sounds. A raw RGBA blob has no header - unlike PNG, you can't peek at the first bytes to learn the width and height. Without the dims, the GIMP plugin has to know the canvas size from somewhere else, which breaks down the moment your output resolution changes (and it will, the first time you upscale). With this node, the size is on the wire.
It's part of comfyui-gimp-nodes, a fork of Acly's comfyui-tooling-nodes modified to speak raw RGBA instead of PNG. Installing is the pack-standard two-liner:
cd ComfyUI/custom_nodes
git clone https://github.com/nchenevey1/comfyui-gimp-nodes.git
...or search "comfyui-gimp-nodes" in ComfyUI Manager. Restart, done. No dependencies beyond what ComfyUI already ships, no model files - the only real requirement is the companion gimp-comfy-tools plugin on the GIMP side.
How it works
For every image in the batch, the node converts the tensor to uint8, base64-encodes the raw RGBA pixels, and prepends the dimensions. The message format, per the README:
14<width><height><RGBA-data>
That's a 32-bit big-endian 14, then the width as a 32-bit big-endian integer, then the height, then the base64 RGBA payload - all pushed over the client websocket via ComfyUI's PromptServer.send_sync, followed by the standard executed JSON. One message per image in a batch.
Inputs and why you'd pick this over the plain one
Just one input: images (IMAGE). It's an output node, so nothing wires out of it - it sits at the end of the graph like SaveImage.
Between the two send nodes, this is the one to default to. The width and height come straight from the tensor's actual shape, so they're always correct, and the plugin can allocate its canvas before a multi-megabyte payload finishes arriving. The plain 12-prefixed variant exists for simplicity and protocol parity, but if you control both ends of this pipe (and you do - it's your GIMP plugin), you're just giving up information by using it.
Common issues
Genuinely thin here, because the mechanism is nearly foolproof. The dims are derived from the tensor, not guessed, so wrong-size canvases almost never trace back to this node - if GIMP renders the result at the wrong size, suspect the plugin's parsing of the 14 framing first. And as with all websocket sends: no plugin connected means the message goes nowhere and the node completes silently. Check the connection before you suspect the node.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — |
Outputs (0)
No outputs