CMK Image Forward -Pipe-

One input, one output, same type, value unchanged. If you're wondering why that's a node at all, the answer is in its own source comment: it exists to expose an incoming IMAGE at a subgraph output without routing it through a processing Prepare or Execute node.

Why that's necessary

CMK's flow architecture is built on typed handoffs. Prepare nodes package state, Execute nodes act on it, and the design notes are explicit that Execute nodes have no pass-through inputs or outputs - because a pass-through is how you end up with a workflow that looks like it's doing something and isn't.

That's a good rule with one obvious problem: sometimes you genuinely just need to get a wire out. You're inside a subgraph, the image is already correct, you don't want a resize or a detailer or a boundary to touch it - you want it visible at the edge of the block so it can be connected or previewed.

That's this node. It's not doing work, it's doing visibility. It's the difference between "the image is in here somewhere" and "the image comes out here", and in a graph with nested subgraphs that difference is the whole game.

Behaviour is deliberately minimal and deliberately strict: hand it a valid IMAGE and you get the same IMAGE back, untouched. Hand it None and it raises CMK Image Forward -Pipe-: IMAGE is missing rather than quietly forwarding an empty value. In a pack whose stated design goal is preventing mis-wiring, an error that names the input is worth more than a null that propagates.

What it tells you about the pack

There are two facts about CMK Flow worth extracting from a node this small.

First, the -Pipe- naming is meaningful. Silent -Pipe- nodes belong to the guided pipeline; the rest is the open toolbox you can wire freely. This one is a plumbing piece for reading a flow, not a tool you'd reach for while building a graph from scratch.

Second, the pack ships a sibling - an image preview forward that shows the completed image while keeping it in the data path. The distinction is instructive: one node forwards, one forwards and displays. Neither processes. That's the discipline the whole pack is built around, and it's why these flows are verbose in a way that turns out to be legible.

When you'd touch it

You're reading a published CMK flow and there's a node sitting on a wire doing nothing visible. That's this. You'll also reach for it if you're structuring your own subgraph - the pattern to steal is "the boundary exposes what it holds, nothing more".

If you were expecting it to convert, resize or re-batch, it doesn't. Even the preview sibling doesn't. For anything that touches pixels, look at the load-and-resize node in CMK/Toolbox/Image.

Install

Manager: search CMK Flow, install the CMKFlow entry, restart. Manually, from your ComfyUI root:

git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

The helper is mandatory after a manual clone - git won't run pip for you, and the pack's dependency list is long enough that skipping it is how you get a pack that half-loads. It ends with CMK dependency check: OK.

This node needs nothing at runtime: no models, no inference, no extra libraries. It's a good canary for whether the pack itself registered cleanly. Weights are a pack-level concern:

python3 custom_nodes/cmk_nodes/scripts/check_cmk_resources.py --models-root "/path/to/ComfyUI-Shared"

One requirement to remember while you're installing: CMK expects ComfyUI's Nodes 2.0 / Vue setting to be on and warns at startup if it isn't. Subgraph-heavy packs like this one are where the old canvas hurts most.

Gotcha

If you wire the output back into the flow in a way that creates a cycle, ComfyUI will complain in its usual way about the graph being invalid - that's the engine, not this node. The reason to mention it is that forwarding nodes feel inert, so people connect them to several places without thinking about where the image came from. It came from somewhere; the node doesn't copy anything, so both consumers are looking at the same tensor.