BBOX Collection to List

If you have ever wired Impact Pack's SEGS-to-BBOX output into a node that obviously ought to run once per box and watched it do something inexplicable instead, you have already met the problem this node solves. In ComfyUI a list is not just a container - a list changes how the graph executes. Impact's legacy BBOX node hands you a single BBOX value that is really a tuple of boxes bundled together. That is exactly right for a node that draws all of them at once, and useless for anything that should run per box. This is the adapter between those two worlds.

The distinction that makes this node exist

Two shapes of "many things" travel around a ComfyUI graph. A collection is one value that happens to contain many items: your node executes once, receives the whole bundle, and does whatever it wants inside. A list is many values: the engine runs the receiving node - and everything behind it that depends on that output - once per item, collecting the outputs as lists as it goes. Same wire, wildly different behaviour.

Impact Pack's SEGS to BBOX emits the collection form, because its job is to feed legacy nodes that want every box in one call. Everything downstream inherits that. The type system cannot help you: both shapes are typed BBOX, so the graph is happy either way and the difference only shows up at runtime.

How it works

Read the source and it is about eight lines, all of which are a guard rail:

• if the input is not a list or tuple, it raises rather than guessing;
• if the input is exactly four plain numbers, it wraps it into a one-item list (that is a single real box being passed through, and you do not want the engine iterating over its x, y, w and h as four separate values);
• otherwise it returns the collection's contents as the list.

That four-number special case is the whole trick. A BBOX is a four-tuple either way, so nothing else in the graph can tell "one box" from "four numbers that used to be a box".

Inputs and outputs

One input, bboxes (BBOX). One output, also named bboxes, but flagged as a list - that flag is the point. Wire the output into whatever should see each box individually: a per-box crop or visualisation node, List Any (Append) to merge boxes from two detectors, or Pipe Set List. If you just want to see how many boxes came out, drop the output into List / Batch Inspector and read count.

Install

It ships inside ComfyUI-Utility-Suite, so you get the whole pack - around forty nodes across Utility Suite/BBOX, Mask, SEGS, Image, Latent and Utilities. ComfyUI Manager → search ComfyUI-Utility-Suite → install → restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/tom-m-2020/ComfyUI-Utility-Suite

Restart ComfyUI. The pack's requirements.txt asks only for opencv-python-headless; the repo has no model downloads at all. It is written against the newer V3 node API (comfy_api.latest), so there is no NODE_CLASS_MAPPINGS in the source and you need a reasonably current ComfyUI - on an old backend the pack fails to import and you will simply see no nodes.

Where people get burned

The collection is a plain Python tuple, so nothing validates it at connect time. Feed this node something that is not a list or tuple - a string, a single BBOX dict from a core node - and it fails at execution with "must be a list or tuple", not on the wire. Read the traceback rather than assuming the pack is broken.

The second trap is the one you came for: remember that the list flag propagates. Everything you wire downstream now runs N times, and if one of those nodes is a save or a sampler, you have multiplied your render time by the number of boxes without meaning to. When you are done with per-box work, collapse it back with BBOX List to Collection, its mirror image.