ImagetoTD(JPEG)

ImagetoTD(JPEG) is the compressed twin of ImagetoTD, and it exists for one reason: bandwidth. The stock node ships images to TouchDesigner as lossless PNGs, which is great until your ComfyUI is a cloud instance sitting on a different network than your TD machine. This variant JPEG-encodes each image at a quality you choose before it ever hits the WebSocket, so the payload is a fraction of the size - at the cost of compression artifacts.

It belongs to the same ComfyUI-TD pack, and the decision between the two is really a decision about your setup. Local box, both apps on the same machine or LAN? Use plain ImagetoTD and enjoy lossless. Remote ComfyUI, cloud GPU, or anything where your connection is less than comfy? This is the node you want, because a small JPEG that actually arrives beats a perfect PNG that stutters or drops.

How it works

Mechanically it's near-identical to ImagetoTD: each tensor in the images batch becomes an image via PIL, then goes out over ComfyUI's WebSocket preview-image event for the ComfyUI2TD.tox to catch and turn into a TOP. The one difference is the encode step - PNG is swapped for JPEG at your chosen quality - and that one change cuts transmitted data dramatically.

The inputs

An output node, so nothing wires onward.

• images - the IMAGE socket, same as the PNG version.
• quality - 1 to 100, default 95. The README recommends 85 as the sweet spot between data size and image quality. At 95 you're barely compressing; at 60-70 you'll start to see blocking on fine detail.
• broadcast - off by default (send only to the queueing client); on for multi-client setups.

Install

Same as the rest of the pack - ComfyUI Manager search for ComfyUI-TD, or:

cd ComfyUI/custom_nodes
git clone https://github.com/JiSenHua/ComfyUI-TD.git

Restart ComfyUI. Dependencies (trimesh, imageio-ffmpeg, soundfile, plyfile) install with the pack. Don't forget the other half: the ComfyUI2TD.tox component from the repo's tox folder, at v5.1.x or newer.

Gotchas

The obvious trap is pushing quality down too far and then wondering why your live output looks crunchy - the pack's own README calls out that JPEG will always be lower quality than the plain node, and 85 is the author's stated balance. On a decent LAN the quality loss is pure downside, so don't use this out of habit; use it when the link is the bottleneck. One more thing to know: if you're running cloud ComfyUI, the pack's 5.1 WebSocket rewrite specifically fixed images not returning under poor network conditions - so keep the tox updated before you blame compression.