cv2.dnn.getInferenceEngineVPUType

Of the three getInferenceEngine*Type probes in this pack, this is the one almost nobody can use - and the honest article is to say so up front rather than pretend otherwise. It reports the VPU plugin type of OpenCV's Inference Engine configuration. VPU here means a Vision Processing Unit: Intel's Movidius sticks and similar edge accelerators. If you're reading this on a desktop with a discrete GPU, you have never had one, and the node is purely theoretical.

What it returns and why it's shaped like that

No inputs, one STRING output. OpenCV's own name for whatever VPU plugin it's configured against - the Myriad-family label is the one that shows up in the docs. It's part of the same legacy introspection family as the backend-type and CPU-type nodes: cv2.dnn used to be able to hand work off to Intel's Inference Engine, and this is the question "and which VPU is it talking to?"

There is no VPU setting to change from here. There's no VPU anywhere in a ComfyUI graph. The node is a read-only field of a configuration that, for 99.9% of installs, has no VPU in it.

So why does the package ship it?

Because the wrapper layer is generated mechanically, in bulk, from OpenCV's type stubs - that's the whole engineering approach of this pack, and the same reason it contains cv2.getStructuringElement next to cv2.ximgproc.anisotropicDiffusion. It doesn't curate by usefulness; it exposes what the library has and lets you decide. The pack's README is unusually candid about the consequences of that (AI-assisted generation, no support, not production-ready), and a node that reports a plugin nobody has is a small, harmless example of the strategy rather than a mistake.

There is a practical payoff to knowing this, though: nodes like this one can be missing on your install and nothing is wrong. Registry entries are probed against the cv2 you actually have, and entries your build doesn't expose are skipped at import. On a 4.8 wheel, this function isn't in cv2.dnn at all. So if your search for "getInferenceEngineVPUType" comes up empty, the answer is your OpenCV build, not the pack.

If you do have a VPU

Then this possibly tells you which plugin OpenCV is pointed at, which is a real question on an edge device - you'd want to know whether inference is going to the accelerator or falling back to the CPU. Check it with the sibling CPU-type node, and if the two disagree with what you asked for, look at the backend setter (cv2.dnn.setInferenceEngineBackendType) - remembering that it mutates process-global state, not a node setting.

Installing comfyui_cv

One of ~470 auto-generated raw cv2.* wrappers in bmad4ever/comfyui_cv, plus curated nodes, GPL-3.0, forked from Gerold Meisinger's opencv-comfyui. Manager: search ComfyUI CV. Or:

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

Restart after install. Python ≥ 3.12 and a recent ComfyUI on the V3 node API; the sole dependency is opencv-contrib-python-headless~=5.0.0.93. Keep the contrib wheel - all four OpenCV distributions overwrite the same site-packages/cv2, last one wins, and a non-contrib opencv-python takes the contrib submodules with it. The pack's tools/repair_opencv_contrib.py --check / --apply is the repair path.

Common issues

It's not in the menu. Expected on most builds - see above.

It raises instead of returning a string. Some builds expose the symbol but fail the call if the plugin can't be queried. That's an OpenCV-level answer about your install, not something the node can paper over.

You wanted something actionable. Honestly, you want CV Build Information. This node is context, not diagnosis.