Split Bboxes

BBOX lists in ComfyUI most commonly come out of a detector node somewhere upstream - Impact Pack's detector providers (its BBOX/SAM/ONNX detectors feeding FaceDetailer or Detailer-SEGS) are the most common source you'll run into. This node doesn't detect anything itself; it just splits a bbox list you already have into two lists at a chosen index, which is the kind of small plumbing step you need once you want to treat part of a detection batch differently from the rest - process your first detected face with more aggressive settings than the secondary ones, say, or separate "primary subject" from "everything else" before two different branches of your workflow handle them.

How the split works

Feed it a bbox list and an index, and you get two lists back: everything before that index in one, everything from that index onward in the other. At index: 0, the first output ends up empty and the second gets everything - there's nothing before position zero to put in the first list.

The inputs and outputs that matter

• bboxes - your source BBOX list, from whatever detector produced it.
• index (default 0) - where to make the cut.
• Outputs: bboxes_a and bboxes_b - the two resulting lists.

How to install it

Standard KJNodes install: ComfyUI Manager → search "KJNodes for ComfyUI" → install, or cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt, then restart. This node itself has no extra dependencies, but you'll need whatever produces your BBOX list in the first place - most commonly Impact Pack's detector nodes - already set up before this is useful.

Common issues & troubleshooting

The split doesn't line up with what you expected as "first" or "biggest." This node splits by list position, not by size, confidence, or location - it has no opinion on what order the bboxes arrived in. If your detector doesn't guarantee a specific ordering (largest-first, highest-confidence-first, or whatever you're assuming), check that ordering before relying on index to reliably grab "the primary detection." If it turns out your upstream detector's order isn't what you need, you may need to sort the list before this node rather than after.

An out-of-range index just gives you an empty list on one side, not an error - an index past the end of your bboxes puts everything in bboxes_a and leaves bboxes_b empty, which is easy to mistake for "nothing detected" if you're not watching for it.

Empty bboxes input produces two empty outputs. If your detector found nothing upstream, don't expect this node to surface an error - it'll happily split nothing into two empty nothings, and the actual problem (no detections) needs debugging further back in the graph.