run yolo bboxs v2

Same job as the original run_yolo_bboxs - run Impact Pack's YOLO-based detector across a batch of images instead of one at a time - with two additions that matter once you're processing anything large: explicit device selection and a batch-size knob. If you were happy with the v1 node, this one is a straight upgrade; the extra controls only cost you two more dropdowns to think about.

It's part of ComfyUI-WJNodes, a personal pack from an author known only by the GitHub handle 807502278, and like its sibling, this node is entirely dependent on Impact Pack - it runs Impact Pack's detector, it doesn't ship its own.

What changed from v1

Functionally, it's the same wrapper: take an already-loaded bbox_detector from Impact Pack, run it across an image sequence, and return bounding box results in WJNodes' own format for downstream consumption. The v2 additions are about controlling how that detection runs, not what it detects:

• device - choose auto, cpu, cuda, or mps explicitly, rather than whatever the detector defaults to. Useful if you're deliberately keeping a detection pass off the GPU while a heavier generation step runs on it concurrently, or if you're on Apple Silicon and want to make sure detection actually uses mps instead of falling back to CPU.
• batch_size - how many images the detector processes per pass, default 4, up to 1024. This is a throughput knob: a larger batch size can process a big sequence faster (fewer round-trips through the model), at the cost of more memory held at once.

Everything else - image, threshold (default 0.5), bbox_detector, input_size (default 1024, up to 4096) - works the same as v1.

Inputs and outputs that matter

• image - the batch to detect over.
• threshold - confidence cutoff for keeping a detection.
• bbox_detector - Impact Pack's loaded BBOX_DETECTOR; this node contributes no detection model of its own.
• input_size - resize before detection; smaller is faster but risks missing small objects.
• device - force where the detector actually runs.
• batch_size - how many frames go through per pass.

Output is the same bboxs collection type as v1, meant for other WJNode nodes downstream (bounding-box-driven crops, for instance) rather than Impact Pack's native SEGS format.

Why the batch-size and device controls actually matter here

The whole point of a "run YOLO across a batch" wrapper is processing a lot of frames efficiently - think a full video sequence rather than a handful of stills. At that scale, the default batch_size may not be tuned to your hardware, and running detection on the same device as your main generation pipeline can create contention you don't want. These two additions are exactly the knobs you'd want once you move from "detect a face in one image" to "detect faces across 400 frames," which is presumably why v2 exists at all.

Installing it

Requires both packs. WJNodes itself:

cd ComfyUI/custom_nodes
git clone https://github.com/807502278/ComfyUI-WJNodes.git

(or via ComfyUI Manager). And Impact Pack, installed the same way - search "ComfyUI Impact Pack" in Manager, or clone ltdrdata/ComfyUI-Impact-Pack directly. Since Impact Pack v8.0, the Ultralytics/YOLO detector provider lives in a separate Impact Subpack install - check for that specifically if you can't find a bbox_detector loader node.

Where people get stuck

Same root cause as v1: if this node errors on a missing type or unknown node, it's almost always the Impact Pack dependency chain, not WJNodes itself. Beyond that, batch_size is the new thing worth watching - pushed too high on a large input_size, it's an easy way to run out of VRAM on a long sequence, especially if detection is sharing the GPU with a generation pipeline running at the same time. Start conservative and raise it once you've confirmed the actual memory headroom you have, rather than maxing it out on the first run of a new sequence.