CV DNN Forward All

CV DNN Forward All loads a model and runs a forward pass that returns all of its unconnected outputs at once. It's the CV DNN Forward sibling for models that don't have a single answer.

Which models are those? Multi-head detection nets - a YOLO segmentation export gives you a detection tensor and a mask-prototype map, and you need both. Optical flow nets that return one field per direction. Anything where the "default output" your other node would return is only half the story.

It also handles .tflite files, picking the loader from the file extension (.onnx → readNetFromONNX, .tflite → readNetFromTFLite).

How it works

Same pipeline position as CV DNN Forward - CV DNN Blob From Image before it, CV DNN Pick Output and a decoder after it, and the forward pass runs in the pack's interruptible DNN worker so it can be cancelled. The difference is what comes back: leave output_layers blank and you get every unconnected output; give it a comma-separated list of names and you get exactly those, in the order you asked.

Outputs are outputs (a list of raw arrays, aligned with the names), output_names (newline-separated, feed Preview as Text), and count.

The multi-input trick, and its limits

The interesting part of this node is input_names, which is how you drive a model that takes two frames - an optical flow net, a change-detection net. Give it a comma-separated list of the network's input names and the blob's batch dimension N is split into K equal groups, one per name.

So if you run a two-frame IMAGE batch through CV DNN Blob From Image and set input_names to 0,1 - the opencv-zoo RAFT export's naming - you're feeding frame group one to input zero and group two to input one. Other exports use image0,image1 or left,right; check the model. N must be a multiple of K.

Two sharp edges here, both spelled out by the author:

• The groups are contiguous, not interleaved. A batch of pairs is laid out as [all first frames][all second frames]. That's fine if you build the batch that way and wrong if you assumed alternating.
• Batching may not work at all, and that's the model's fault, not the node's. Many two-input exports freeze batch 1 into their constants. Feed a two-pair blob to one of those and it dies in a Concat layer with "Inconsistent shape". Feed one pair per execution and loop. The tooltip names opencv-zoo RAFT as exactly this case, and adds another gem: on the graph engine that export returns an all-NaN field for some input pairs whatever the engine widget says - the pack's dense-flow node recovers most of them by re-running with input_names reversed and negating the flow. Good luck deducing that from a NaN.

All groups share one blob's preprocessing, so this only fits models whose inputs are images of the same size and scaling. A model mixing an image with a differently-shaped input is out of reach.

Inputs and outputs

Required: blob (NCHW, from CV DNN Blob From Image) and model (.onnx or .tflite from ComfyUI/models/onnx).

Optional: output_layers (blank = all unconnected outputs), input_names (blank = one unnamed input, right for the usual case), and the backend / target / engine trio. On this build, the first two do nothing - the graph engine ignores them, OpenCV 5.1 removed the classic engine that honoured them, and this wheel has no CUDA, no OpenVINO and no OpenCL. The engine choice still matters for loading; ONNX Runtime needs a build with WITH_ONNXRUNTIME=ON, and auto is the only meaningful choice on 5.1.

Install

Part of comfyui_cv (bmad4ever/comfyui_cv). Search "ComfyUI CV" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv
pip install "opencv-contrib-python-headless~=5.0.0.93"

Then restart ComfyUI. Python ≥ 3.12 and a recent V3-API ComfyUI. Models aren't bundled - put them in ComfyUI/models/onnx and consult model_sources.txt for download URLs and licences. Note the licence warning in the README before you republish anything: yolo26n-seg.onnx is AGPL-3.0 with a network clause, and one of the LLM/VLM models isn't redistributable at all.

Common issues

• "Inconsistent shape" in a Concat layer. A two-input model being fed more than one pair. One pair per execution, loop for the rest.
• The output list order surprises you. It matches output_names - read that output rather than assuming index 0 is the detection head.
• The blob's batch doesn't divide by the number of input names. N must be a multiple of K exactly.
• Shapes are wrong and you're guessing. Inspect CV Data on each output before you wire a decoder. Detection heads come in at least four different layouts, which is precisely why CV YOLO Detect Decode has four named modes.
• You're tempted by backend/target anyway. They're listed because the build exposes the options, not because they work. If a model is too slow, the fix is a smaller model or the CPU budget, not a compute backend.