Nodes/MKRShift_Nodes/Nuke Read Plan
ComfyUI Node

Nuke Read Plan

Plan a Nuke Read node from ComfyUI, before a single pixel moves

By criskb·Created 7 months ago·Updated 5 months ago· 0
Nuke Read Plan
    • nuke_read_plan_json
    • manifest_line
    • summary_json
    asset_path
    node_nameRead_MKRShift
    colorspacedefault
    frame_modesingle
    script_context_json
    transport_plan_json
    notes

    MKRNukeReadPlan builds a return plan for getting generated assets back into Nuke as Read nodes. It's a pure JSON builder: feed it a path and some intent, and it hands you a structured plan plus a manifest line. Nothing is written, nothing is imported - that's MKRNukeReadOutput's job - but this node is where you decide what the Read node will look like before it exists.

    Think of it as writing down "this file, this colorspace, this frame range, this node name" on paper, then handing the paper to the part of the pipeline that acts on it. Because the plan is just JSON text you can inspect, you can also wire it into logging, manifests, or the pack's studio/delivery nodes, which consume manifest_line outputs happily.

    The inputs that matter

    • asset_path - where the render will live. Must be reachable by both ComfyUI and Nuke. This is the one field that actually has to be right.
    • frame_mode - single (one still), sequence (a numbered frame set), or movie (a video file). This changes how the Nuke bridge builds the Read: sequence gets a frame pattern, movie gets a file reference. Set it to match what you'll actually write, or your Read will point at nothing.
    • node_name - the name the Read gets in the script (Read_MKRShift default). Reusing the same name across runs means the bridge updates that one node instead of stacking new Reads.
    • colorspace - passed through to the plan so the bridge can set the Read's colorspace (default just means "Nuke's project default").

    The optional script_context_json can carry Nuke-side context like root_format or viewer_process (the bridge panel can supply this), and transport_plan_json lets you bolt a transport plan onto the handoff. notes is freeform - the plan's notes field, useful for documenting in the manifest.

    The outputs

    • nuke_read_plan_json - the plan proper, schema mkrshift_nuke_read_plan_v1. Wire this into MKRNukeReadOutput.
    • manifest_line - a comma-joined line: node name, frame mode, colorspace, path. Perfect for a text log or a manifest collector.
    • summary_json - node name, frame mode, whether a path exists, whether a transport plan is attached, and warnings.

    Installing

    One pack, one install:

    cd ComfyUI/custom_nodes
    git clone https://github.com/criskb/MKRShift_Nodes
    

    restart, done. Or ComfyUI Manager → search "MKRShift". No dependencies beyond ComfyUI's own stack, no model files.

    Gotchas

    The classic mistake is mismatch between plan and reality: frame_mode: movie in the plan while MKRNukeReadOutput writes a PNG sequence, or an asset_path that only one machine can see. Because this node is pure and never validates the path, "no warnings" is not the same as "will work." Also, manifest_line is just text - if you're feeding it into a manifest node, make sure that node expects this format (comma-joined) rather than JSON, or you'll get a parse headache you didn't need.

    CategoryMKRShift Nodes/Addons/Nuke

    Inputs (7)

    NameTypeDefaultDescription
    asset_pathSTRING
    node_nameSTRINGRead_MKRShift
    colorspaceSTRINGdefault
    frame_modeCOMBOsingle3 options: single, sequence, movie
    script_context_jsonoptSTRING
    transport_plan_jsonoptSTRING
    notesoptSTRING

    Outputs (3)

    NameTypeDescription
    nuke_read_plan_jsonSTRING
    manifest_lineSTRING
    summary_jsonSTRING