Nuke Image Output Plan
Tell Nuke how to receive your render without ever touching Nuke
- image_output_plan_json
- manifest_line
- summary_json
MKRNukeImageOutputPlan is the planner half of the Nuke roundtrip. It doesn't write a single pixel - it produces a JSON plan that describes where a render should land and how Nuke should treat it when it gets there. You wire that plan into MKRNukeImageOutput, which does the actual file write, and the Nuke-side bridge addon (shipped with the pack under addons/nuke/) does the actual importing.
That split is the pack's whole design philosophy: plan nodes are pure, deterministic string builders. They never touch the filesystem, never fail on permissions, and you can chain and reuse them freely. The runtime nodes do the risky work. It sounds backwards until you're iterating on a look at 3am and realize you can retarget the whole output lane just by changing one plan node.
The inputs that matter
- asset_path - the destination for the file. Make this a real path on a drive both ComfyUI and Nuke can see. No path, no handoff; the output node will warn.
- apply_mode - how Nuke should consume the file:
read_node- the default, and the one you'll use 90% of the time. The file becomes a Read node in the script.deep_read- Read node with deep-image handling; for when you're handing off something with deep data or a heavy comp context.viewer_input- push it straight to a viewer, for quick look checks without cluttering the node graph.
- image_role - a free-text label (
plateis the default). This is metadata for the bridge so the Nuke panel can sort/route the asset. - target_name - the node name to use in Nuke (
Read_MKRShiftby default). Reusing the same name across runs makes the addon update an existing Read instead of spawning new ones, which keeps comps tidy.
The optional colorspace field is passed through to the plan and honored by the bridge when it sets up the Read, and target_script_name lets you aim at a specific .nk if you run multiple. transport_plan_json is the pack's way of attaching a transport plan (from the endpoint-plan family) to the same payload - most people leave it empty.
The outputs
- image_output_plan_json - the actual plan. This is the wire to MKRNukeImageOutput.
- manifest_line - a compact CSV-ish line (node name, apply mode, path) you can shove into a manifest or log. The publish/studio nodes in this pack love these.
- summary_json - structured confirmation of what the plan contains, plus warnings.
Installing
Same as every node in this pack - it's one pack, one install:
cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes
then restart ComfyUI (or use ComfyUI Manager and search "MKRShift"). No dependencies beyond what ComfyUI already ships, no model files to download.
Gotchas
Because the plan is just JSON text, you can inspect it directly in the node - if asset_path looks wrong there, nothing downstream will fix it. The most common mistake is leaving asset_path empty and expecting the output node to invent a path. It won't. Also worth knowing: this node is pure - nothing is written or registered anywhere when it runs. So "it ran fine" tells you nothing about whether Nuke can actually read the path later. Keep the path on a filesystem both sides can reach, and remember the ComfyUI half of this bridge only ever produces files; the Nuke addon is what turns those files into nodes.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| asset_path | STRING | — | |
| image_role | STRING | plate | — |
| target_name | STRING | Read_MKRShift | — |
| apply_mode | COMBO | read_node | 3 options: read_node, deep_read, viewer_input |
| colorspaceopt | STRING | default | — |
| target_script_nameopt | STRING | — | |
| transport_plan_jsonopt | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| image_output_plan_json | STRING | — |
| manifest_line | STRING | — |
| summary_json | STRING | — |