🌀 BV External Detector Binding (Advanced)

BV Detector Binding is the optional advanced input to the BV detailer loop - and the README is refreshingly direct about it: it's "not required when models are configured in BV Detector Registry." If that sentence describes you, close this tab and move on with your life. You'll wire the registry to the plan and never touch this node.

But there's a real case for it. The Registry loads detectors inside the BV node, from Impact's own providers. If your detector comes from somewhere else - another node pack, a custom BBOX/SAM pipeline you already built - there's no way for the registry to know about it. Binding is the adapter that takes an external detector object and hands it to the loop under a stable ID.

How it works

The node wraps up to three optional detector objects into one BV_DETECTOR_BINDING, and the important part is that it validates capabilities instead of trusting them. Impact's detector ecosystem is full of placeholder outputs - notably, an Ultralytics BBOX model exposes a segmentation sentinel that isn't actually functional. The binding checks whether each object really has a callable detect method and records what's usable, so a fake segmentation capability doesn't get treated as a real one downstream. You give it a detector_id, and the binding's capabilities reflect only what's genuinely connected.

Inputs

• detector_id (STRING, default detector) - the stable name the plan will reference when a job uses this detector. Must be non-empty and unique within the registry.
• bbox_detector (BBOX_DETECTOR) - optional, a bounding-box detector from another pack.
• segm_detector (SEGM_DETECTOR) - optional, a segmentation detector.
• sam_model (SAM_MODEL) - optional, a SAM model for mask refinement. BV treats it as opaque; Impact validates the actual contract.

Outputs

• detector_binding (BV_DETECTOR_BINDING) → wire into one of the Registry's external_detector_1..10 inputs.
• detector_id (STRING) - the ID you set, for chaining.
• has_bbox, has_segmentation, has_sam (BOOLEANs) - the capability flags, useful for checking the adapter saw what you thought you connected.

Installing and using it

Part of BV Node Pack - same install as the rest of the loop:

cd ComfyUI/custom_nodes
git clone https://github.com/BlackVortexAI/bv_nodepack.git

Restart and hard-refresh (Ctrl+F5). Because the registry and the Detect-to-SEGS node route through Impact's machinery, keep ComfyUI-Impact-Pack installed even on this path.

The practical flow: build the binding from your external detector → drop it into the Registry's external_detector_1 → the Registry validates it has an id and registers it → the plan's detector dropdown picks it up by name. The has_* booleans are there so you can confirm the binding before the plan validates it and errors.

Common issues

• "detector_id must be non-empty". The ID is what the plan references; a blank one is rejected immediately.
• "external_detector_1 has no detector_id; rebuild it with BV Detector Binding". The Registry only accepts proper bindings, and the fix is in the error message: rebuild the binding.
• Detect-to-SEGS fails at run time despite has_bbox = True. The binding records capability, not health - if the detector object itself is stale or unloaded, detection fails downstream. Re-run the binding's source node to refresh it.

The verdict: this is the node for people mixing detector ecosystems, and it's very good at being out of the way for everyone else. If you're using the Registry's built-in loading, you don't need it - that's a feature, not a limitation.