Image Bridge

At first glance this node does nothing: it takes an IMAGE in and hands the same IMAGE back out. No processing, no options beyond the single required input. That's not a bug - it's the point. RiceRoundImageBridgeNode exists so you can mark a specific edge in your graph as "this is where an externally supplied image belongs," even when the pixels feeding it during local testing come from somewhere else in your own workflow rather than a file you picked by hand.

Why you'd want an identity node

RiceRound's publish step, RiceRoundEncryptNode, works by recognizing RiceRound's own Input-category nodes in your graph and turning each one into an editable field on the page it generates. RiceRoundImageNode (the file-picker version, basically core LoadImage with RiceRound branding) covers the case where you're testing with a static local file. But sometimes the image your published workflow needs isn't something you'd pick from a dropdown at all - maybe it's the output of an earlier processing step, or something you're wiring in for testing that will be substituted by real user input once live. Image Bridge lets you register that connection point as a RiceRound-recognized input without forcing it through the file-picker widget.

The input and output that matter

• images (required, IMAGE) - its tooltip just says "only image," a terse but accurate description: this socket strictly wants image data, nothing else.
• Output: value (IMAGE) - the same image, passed straight through. Wire it onward exactly like you would the source image itself.

If you need the mask equivalent of this same pattern, that's RiceRoundMaskBridgeNode - same idea, MASK type instead of IMAGE.

Installing it

Search "RiceRound" in ComfyUI Manager and install, or clone it manually:

cd ComfyUI/custom_nodes
git clone https://github.com/RiceRound/ComfyUI_RiceRound

then restart ComfyUI. Nothing in the README calls for extra dependencies or model downloads for this pack - it's a packaging and publishing layer over a workflow you've already built, so the install itself is lightweight.

Common issues & troubleshooting

It's not obvious why you'd use this instead of just wiring the image directly. If you're never going to publish the workflow, you're right - there's no reason to insert a passthrough node for its own sake. Its value is specifically in how RiceRound Publish reads your graph; if that step depends on seeing one of its own recognized nodes at the input boundary, a raw wire from an arbitrary upstream node may not register as a proper published input the way a Bridge node does. The README doesn't document this mechanism explicitly, so this is the most defensible reading of why the node exists at all, not a documented guarantee.

Should this be in the workflow you actually publish? Yes - it's Input-category, which per the README is exactly the family of nodes meant to end up in the graph you run through RiceRound Publish, as opposed to the separate Output-category nodes meant only for local debugging.

You're trying to decide between this and RiceRoundImageNode. Use RiceRoundImageNode when you want a static local file you pick from a dropdown. Use this one when the pixels are already flowing through your graph from somewhere else and you just need to flag that point as an input boundary for RiceRound's tooling to recognize.