Zura V3 · Plan-only images

Zura V3 · Plan-only images does one thing: it lets an image through during the planning pass and refuses to during the render pass. It's the gate that keeps your camera-angle branch - the one that generates nine candidate stills with your edit model - from firing again every time you hit queue for a render.

Small node, real savings. Nine image edits per shot plan is not free.

Inputs and output

Required: stage, which you take from Zura V3 · Choose pass. Optional: image, which is declared lazy.

One output, IMAGE.

How it behaves

Set the stage to 1 · Plan angles and the node returns the image it was given. If nothing is connected it raises Connect the look image for the planning pass. - a clear message, which is more than most graph-plumbing nodes manage.

Set the stage to 2 · Render multicam and it returns an ExecutionBlocker on its output. That doesn't just pass a null downstream; it prunes the whole branch behind the node from the execution graph. Anything purely downstream of this node - the angle image generation, the previews of it - simply doesn't run.

It also implements check_lazy_status, so during the render pass it never even asks upstream for the image. The branch is never evaluated in the first place.

Install

It ships in the multicam pack. Nothing extra to add:

cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes

Restart ComfyUI, or install Zura Nodes through ComfyUI Manager. No model files, no heavy dependencies. The pack's requirements.txt extras (requests, yt-dlp, ultralytics, face-alignment) belong to the video-loading and detection nodes, not this one.

Where this bites

Because the branch is blocked rather than muted, every consumer downstream has to tolerate a blocked input. Preview nodes do - they just show nothing. A node that needs a real value does not, and there is no clean way to fetch the image on the other side of the gate during a render pass.

So the pattern if you need the planning image outside the planning pass: keep a second, ungated connection from the same source instead of trying to reach through this node. The point of the gate is that the expensive stuff stops happening; fighting it means defeating it.

The other thing to internalise is that this node is the pair to Plan-only images' opposite number, the H3 render node, which does the same trick with ExecutionBlocker on its two outputs. Both exist so that one shared graph can do two very different jobs on one dropdown, and both depend on the stage value being right. If the branch ran when it shouldn't have, look at your stage wiring before anything else.