Extract Bounding Box
Pull x, y, width, height out of any bbox-shaped data
- input_data
- x
- y
- width
- height
- bounding_box
Bounding boxes are everywhere in ComfyUI - detection models emit them, crop nodes consume them, and some nodes hand them to you as a JSON string while others hand you a structure, and they're never in the shape the next node wants. UC_ExtractBoundingBox is the plumbing that reconciles the mismatch: it digs through whatever you give it, finds the bounding box(es), and hands you the raw numbers plus a clean BOUNDING_BOX structure.
The input socket is * - any type - which is the honest way to build a node like this, because bbox data arrives as JSON strings, Python dicts, lists, or nested structures depending on what produced it. The node handles all of them: if the input is a string it tries to parse it as JSON, then it recursively walks dicts, lists, and tuples looking for anything that has x, y, width, and height keys. The index input (default 0) picks which box when there are several, and everything is coerced to integers.
Outputs are the contract in order: x, y, width, height as separate INTs, plus a combined bounding_box output of type BOUNDING_BOX. That last one is the quiet hero - Core's own PrimitiveBoundingBox exists precisely to give crop, paste, and region nodes a rectangle without four loose wires, and this node produces the same structure from data that came from somewhere else. So the workflow pattern is: detection node spits out a JSON list of boxes → extract the one you want → feed bounding_box (or the four ints) straight into a crop or region node.
The failure modes are the ones you'd hope for: it raises a clear error if no box-shaped data is found at all, and an out-of-range index gets a message telling you how many boxes were actually found. That's the right behavior - this is a node where silent fallback would be actively harmful, because a wrong crop region ruins the downstream work quietly.
Where this earns its keep: region-based editing, object cropping, and any workflow where a detector (like the pack's Ideogram 4 bbox crop or a detection-model output) hands you coordinates you need to turn into an actionable region. It's also the kind of node that saves you from writing a JSON-parse node pair by hand every time a model output changes shape.
One tip from the source: it looks for dicts that have all four keys (x, y, width, height) - if a producer names them differently (e.g. bbox_x or x1,y1,x2,y2), this node won't see them. That's a real constraint worth knowing before you blame the node.
Install is pack-standard: Manager search "ComfyUI-UtilsCollection" or cd ComfyUI/custom_nodes && git clone https://github.com/silveroxides/ComfyUI-UtilsCollection then restart. No models, no downloads. Pure data plumbing - boring, correct, and occasionally the exact node that unblocks a workflow.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| input_data | * | Input data containing bounding boxes (JSON string, list, dict, or nested structure) | |
| index | INT | 00–9223372036854776000 | Index of the bounding box to extract |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| x | INT | — |
| y | INT | — |
| width | INT | — |
| height | INT | — |
| bounding_box | BOUNDING_BOX | — |