cv2.dnn.getInferenceEngineBackendType

No inputs, one output, and the output is a string. That's the entire node: it asks OpenCV which DNN backend is currently in use and prints the answer.

This is legacy OpenCV territory. cv2.dnn used to be able to delegate to Intel's Inference Engine (OpenVINO) as an alternative to its own implementation, and the getInferenceEngine*Type family exists to introspect that arrangement. The return value is one of the backend-type names OpenCV documents - the OpenCV-native setting, or the Inference Engine one when it's delegating. On a normal pip wheel you'll see the native value; the point of the node is confirming that rather than assuming it.

Is this worth a slot in your graph?

Honestly? No - not as a working node. It's a diagnostic, and it belongs in the category of "run it once when something is weird". The genuinely useful question it answers is what backend your CV DNN Forward calls are actually running through, because that's the difference between "the ONNX is slow because it's CPU-bound on OpenCV's own kernels" and "the ONNX is slow because it handed off somewhere unexpected".

Pair it with the pack's CV Build Information node and you have a complete one-screen answer for a bug report. That's not a throwaway suggestion: this pack deliberately blacklists the raw cv2.getBuildInformation wrapper, because the build banner is frozen at compile time and quotes the build machine's directories, user names and compiler paths verbatim. CV Build Information serves the same text with the paths redacted. If you're about to paste build output into an issue, that's the node to run.

Practical notes

The STRING output wires into anything that takes a string - a note, a text preview, or the pack's text/array helpers. Since the node has no inputs, it runs once and returns the same value every time; nothing about your image changes it. Run it, read it, right-click and delete it.

The thing to know before you get confused: these nodes only exist on OpenCV builds that still expose the function. The pack's registry is generated from OpenCV's type stubs and then probed against your installed cv2 at import time, so any entry your build lacks is skipped. I checked the Python bindings on a 4.8 wheel and the whole getInferenceEngine*Type family is simply gone from cv2.dnn there. So if this node isn't in your menu after installing, that's not a broken install - your OpenCV doesn't have the API. Same package, different wheels, different available nodes. Worth internalising for this pack generally.

Installing comfyui_cv

This node ships in bmad4ever/comfyui_cv: about 470 auto-generated raw cv2.* wrappers plus curated nodes, a GPL-3.0 fork of Gerold Meisinger's opencv-comfyui. Install from ComfyUI Manager by searching ComfyUI CV, or:

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

Restart afterwards. You need Python ≥ 3.12 and a recent ComfyUI built on the V3 node API; the single dependency is opencv-contrib-python-headless~=5.0.0.93. Keep the contrib build: all four OpenCV wheels share one site-packages/cv2 and the last one installed wins, so an opencv-python install over it silently strips the contrib submodules and their nodes. tools/repair_opencv_contrib.py --check diagnoses it, --apply repairs it.

Common issues

The node isn't in the menu. Your OpenCV build doesn't expose the function - see above. Check which wheel is installed rather than reinstalling the pack.

Backend value looks wrong after you changed something. You probably ran the sibling setter, cv2.dnn.setInferenceEngineBackendType, somewhere in the graph. It changes process-global state, not a per-node setting.

You wanted the build banner instead. Use CV Build Information. It's the same information with the machine's paths redacted, and it's the version that's safe to share.