BBox Detector (Batch ForEach)

BBox Detector (Batch ForEach) is the third variant in NodeSweet's detection trio, and it exists for a specific structural reason: ComfyUI has two idioms for "lots of images," and the other two nodes only handle one of them. BboxDetectorBatch and the Chunked version expect a single stacked IMAGE tensor - batch-of-4D, one big array. But a chunk of ComfyUI's ecosystem - especially list-aware processing and certain workflow patterns - passes images around as lists of tensors. This node is built for that world, via ComfyUI's INPUT_IS_LIST mechanism.

So the mechanism difference is the interface, not the detection. The node is marked INPUT_IS_LIST = True and OUTPUT_IS_LIST = (True, True), meaning it receives images as a Python list of tensors and hands back lists of images and masks. For each tensor in the list it runs the same detect_combined(threshold, dilation) call that the other two variants use - and since the input items can themselves be batched ([B, H, W, C]), it takes the first frame when it meets a batch, otherwise treats the item as a single image. bbox_detector, threshold, and dilation are each read from [0], i.e. the single value of their lists.

Inputs are the same core trio as the standard node - bbox_detector (ImpactPack BBOX_DETECTOR), images (a list), threshold (default 0.5), dilation (default 4). There's no return_type or chunk_size here. Outputs are images and masks as lists, preserving the input order, one mask tensor per image.

Why pick this over the batch variant? Two reasons. First, if your upstream genuinely hands you a list - some list-native nodes don't offer a single stacked tensor - this saves you a stack/unstack round-trip and keeps the data shape stable. Second, memory: because you're processing list items one at a time without building one giant tensor, it can be kinder to VRAM in certain graph shapes, which is exactly the "list-based workflows" niche the README points at.

The honest caveats are shared with its siblings. The detection still runs frame-by-frame on the CPU/GPU of your detector - this is not a throughput win, it's a shape-compatibility win. And like all three bbox nodes, it needs the full ImpactPack stack to exist at all: Impact Pack for the BBOX_DETECTOR type, Impact Subpack (separate since Impact Pack v8.0) for UltralyticsDetectorProvider, plus a YOLO model - the shared Bingsu/adetailer weights work. NodeSweet itself ships no requirements.txt and no model files; the heavy lifting lives entirely in ImpactPack.

Install the pack the usual way - ComfyUI Manager, search "Batch BBox Detector", Install, or:

cd ComfyUI/custom_nodes && git clone https://github.com/rslosch/comfyui-nodesweet

then restart. If your masks come back black, lower threshold toward 0.3–0.4 or verify the detector model loaded; that's the standard diagnosis and it applies here exactly as it does to the batch variant.

Bottom line: if you're feeding it a single stacked batch, use BboxDetectorBatch (small) or BboxDetectorBatchChunked (large). If your workflow is list-shaped, this is the one that fits - a thin adapter, but adapters are exactly what batch-heavy workflows end up missing.