cv2.dnn.getInferenceEngineCPUType

Zero inputs. One STRING output. It asks OpenCV which CPU plugin type its DNN module is currently configured with and hands you the name back.

That's the whole node, and the value of it is precisely that nothing interesting happens. You are running a ComfyUI install on a desktop CPU; the answer will be the plain CPU flavour, every time, on every run. Nobody wires this into a pipeline. It's a node you add for thirty seconds while diagnosing "why is my ONNX inference suspiciously slow" and then delete.

Why it exists at all

cv2.dnn historically had two lives. It could run networks itself, or delegate to Intel's Inference Engine (OpenVINO) - and once delegation is on the table, all the introspection questions follow: which backend, which CPU plugin, which VPU plugin. The getInferenceEngine*Type family is that introspection surface, and this is the CPU one. It tells you what the CPU path is called in your build, which matters only when something upstream has switched the process into a delegate mode and you want to know what it delegated to.

If you're looking for the switch itself, that's the sibling node cv2.dnn.setInferenceEngineBackendType - and the honest advice is to leave it alone.

Reading the output

The STRING output wires into anything that accepts a string: a note node, a text preview, the pack's text helpers. Since there are no inputs, the node has nothing to depend on, so it runs once, returns one value, and would return exactly the same value on every subsequent execution. It's a constant with extra steps - which is fine, because the thing it's reporting is genuinely a property of your installation, not of your graph.

The catch worth knowing before you hunt for a bug: this node may not exist on your machine, and that's correct behaviour, not a broken install. The pack generates its ~470 raw wrappers from OpenCV's type stubs and then probes each one against the cv2 that's actually installed, skipping anything the build doesn't expose. I checked a stock 4.8 wheel: the entire getInferenceEngine*Type family is gone from cv2.dnn there. Different wheel, different node list.

And if the answer you actually need is "what is this cv2 build", use the pack's CV Build Information node instead. It's the build banner with the machine's filesystem paths redacted - the raw cv2.getBuildInformation wrapper is deliberately blacklisted by this pack specifically so that pasting build output into a bug report doesn't leak your home directory and compiler paths. That node is the one to reach for; this one is a single field of it.

Installing comfyui_cv

From bmad4ever/comfyui_cv: roughly 470 auto-generated raw cv2.* wrappers plus a curated node layer, a GPL-3.0 fork of Gerold Meisinger's opencv-comfyui, curated against OpenCV 5.0.0.93. In ComfyUI Manager, search ComfyUI CV, or:

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

Restart after. Requires Python ≥ 3.12 and a recent ComfyUI on the V3 node API; the only dependency is opencv-contrib-python-headless~=5.0.0.93. Contrib, not plain - all four OpenCV distributions share one site-packages/cv2 and the last install wins, so a later opencv-python silently empties the contrib submodules and their nodes. tools/repair_opencv_contrib.py --check and --apply are the pack's own fix for that.

Common issues

Not in the node menu. Your OpenCV build doesn't expose the function. Verify with python -c "import cv2; print(hasattr(cv2.dnn, 'getInferenceEngineCPUType'))" before you touch the pack.

You expected a CPU feature list. This is a plugin-name string, not CPU introspection. For hardware detail, CV Build Information or your OS tools.

You changed it and nothing else changed. You can't set the CPU type here; that's the backend setter, and it's process-global.