🌀 BV Detector Registry

In a stock Impact Pack workflow, each detector means its own provider node, its own binding, possibly a chained registry - a wall of plumbing before you even reach the detailer. BV Detector Registry collapses all of that into one node: you configure a handful of named detectors (Ultralytics, ONNX, optionally SAM), it loads them through Impact's installed providers internally, and hands the whole bundle to BV Regional Detailer Plan as a single detector_registry wire.

The README frames it as the ergonomic win it is: "no visible Impact provider chain is required." For ordinary workflows you configure detectors here, assign them to jobs in the plan dialog, and never think about BBOX_DETECTOR plumbing again.

How it works

The registry is a mapping from stable detector IDs to capability-validated bindings. Configure it through the node's dialog (or config_json directly), which produces a small JSON document of the form:

{
  "schema": "bv.detector_registry_config",
  "version": 1,
  "detectors": [
    { "id": "face", "provider": "ultralytics", "model_name": "face_yolov8n.pt" },
    { "id": "hand", "provider": "ultralytics", "model_name": "hand_yolov8n.pt", "sam_model_name": "sam_vit_b.pth" }
  ]
}

Each entry declares an id, a model_name, a provider (ultralytics or onnx), and optionally a sam_model_name with a sam_device_mode. At execution the node pulls the matching Impact providers - UltralyticsDetectorProvider, ONNXDetectorProvider, SAMLoader - out of ComfyUI's node registry and loads the models. That's the "no visible provider chain" part: it's all inside this one node.

The external_detector_1 through external_detector_10 inputs are the escape hatch for detector objects built elsewhere - plug a BV Detector Binding in there to add a third-party detector alongside the configured ones.

Inputs and outputs

• config_json - the JSON configuration (filled by the dialog).
• external_detector_1..10 - optional BV_DETECTOR_BINDING inputs for detectors supplied by other nodes.

Outputs: detector_registry (BV_DETECTOR_REGISTRY) → BV Regional Detailer Plan; detector_count (INT) and registry_summary (STRING) for quick sanity checks.

Installing it

Part of BV Node Pack (Manager: search "BV Node Pack", or git clone https://github.com/BlackVortexAI/bv_nodepack.git into custom_nodes), then restart and hard-refresh. The real requirement is ComfyUI-Impact-Pack: the providers this node loads live there, and since Impact v8.0 the Ultralytics provider moved into the separately-installed Impact Subpack - so if you get a "requires the Impact provider" error, check both are installed. Detector weights come from Impact's detector model folder; BV bundles none.

One caution worth carrying from the detailing ecosystem: Impact's YOLO path runs on Ultralytics, which has a documented supply-chain history (a compromised release reached ComfyUI users through Impact in December 2024). Keeping the Ultralytics Subpack to what you actually use is cheap insurance.

Common issues

• "BV Detector Registry requires the Impact provider 'X'". Impact Pack (and Subpack for Ultralytics) missing or ComfyUI not restarted since install.
• Invalid JSON / wrong schema. config_json must be a valid bv.detector_registry_config v1 object; the dialog writes it correctly, hand-editing is where people break it.
• Duplicate detector IDs. Each id must be unique across the registry.
• External binding with no detector_id. A BV_DETECTOR_BINDING input that isn't a valid binding gets rejected with a message to rebuild it via BV Detector Binding.

The one-line verdict: if you're using the BV Detailer Loop at all, put your detectors here - it's the path of least resistance, and the plan dialog's detector dropdown reads straight from it.