cv2.dnn.readTensorFromONNX

ONNX is mostly known as a model format, but it's also just a container for tensors - and this node reads one out. You give it a path to an .onnx file that holds a tensor instead of a graph, and you get that tensor back as an NPARRAY you can then feed into anything in the pack.

Why you'd ever want this

The historical reason is mean subtraction. Classification models in OpenCV's tutorials needed a mean file, which used to ship as Caffe's mean.binaryproto; when the ecosystem moved to ONNX, the sane way to carry that same tensor was to convert it to ONNX and read it back with this call. So the canonical use case is "a small numeric blob that lives in a file, produced by a script, consumed by a graph" - authored in numpy, exported to ONNX, read here.

In a ComfyUI workflow that's a real convenience. The pack's other route into "some numbers as data" is text: Parse Matrix for delimited text, CV Points for a point literal, CV Scalar for a constant vector. Those are fine for twenty numbers. When the tensor is a 224×224 mean image or a calibration table with thousands of entries, you want the binary file, and this is the node that reads it.

It's also how you sanity-check a conversion. Wrote a script that exported a mean/PSF/gain-map tensor? Read it back into the graph and look at it before you trust the pipeline downstream.

Inputs and outputs

Required: path, a string. The widget comes up blank because the type stubs carry no default, and - unlike the pack's blank = OpenCV default literal widgets on optional parameters - this one is required, so blank is passed to OpenCV as an empty string. Type a real path, absolute or relative to the ComfyUI process's working directory.

Output: nparray, a single tensor. Not an image, no format echo. Hand it to Preview CV Array to see it, CV Array To Text to read it as numbers, or straight into another raw cv2.* node.

Worth knowing about the pack's policy here, because it explains something you might trip over: this is one of very few nodes in comfyui_cv that takes a filesystem path. The generator deliberately blacklists the imread/imwrite family and their relatives - the comment in the source says arbitrary host paths are "a path-traversal surface a shared workflow could aim anywhere", and ComfyUI already has Load Image. readTensorFromONNX survives that filter, which means it's the exception: a string path, resolved by OpenCV, no ComfyUI path allowlist involved. Treat downloaded workflows with the usual level of trust.

Installing comfyui_cv

Part of bmad4ever/comfyui_cv - ~470 auto-generated raw cv2.* wrappers plus curated nodes, a GPL-3.0 fork of Gerold Meisinger's opencv-comfyui, curated against OpenCV 5.0.0.93. Manager: search ComfyUI CV. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv

Restart. Python ≥ 3.12 and a recent ComfyUI built on the V3 node API; one dependency, opencv-contrib-python-headless~=5.0.0.93. Install the contrib wheel - all four OpenCV wheels share one site-packages/cv2, last install wins, and a non-contrib opencv-python silently strips the contrib submodules and their nodes (tools/repair_opencv_contrib.py --check / --apply).

Common issues

(-5:Bad argument) Can't read ONNX file: <path>. The path is wrong, or the file isn't where you think it is. Relative paths resolve against the ComfyUI process's working directory, not against your custom_nodes folder - use an absolute path when in doubt.

(-210:Unsupported format or combination of formats) Failed to parse ONNX data: <path>. The file exists but isn't an ONNX tensor. This is what you get if you point it at a PNG or a .safetensors, which is a surprisingly easy mistake to make when the paths all look alike.

It reads a model file and gives you nonsense. An ONNX graph isn't a tensor. This call expects a file holding a tensor, not a network.

Errors arrive anyway? ComfyUI surfaces the failure as a RuntimeError that includes OpenCV's full message and the arguments, so the two errors above are normally visible verbatim rather than swallowed - which is the only reason this node is debuggable at all.