BBOX xywh to xyxy

Two families of bounding box live side by side in ComfyUI and they disagree about what the third and fourth numbers mean. Core's BOUNDING_BOX structure - the thing PrimitiveBoundingBox makes and crop/paste nodes consume - is x, y, width, height. Impact Pack's SEGS entries and most of the detection ecosystem hand you x1, y1, x2, y2. Feed one to a node expecting the other and you rarely get an error. You get a rectangle in the wrong place with the wrong size, and you spend twenty minutes deciding whether your detector is bad.

This node is a four-number translator, and it exists so you convert at the boundary instead of debugging geometry.

How it works

One bbox in, one bbox out, plus a conversion dropdown with two options: xywh to xyxy and xyxy to xywh.

The arithmetic is the boring part: xyxy is (x, y, x + w, y + h), and back again it is (x, y, x2 - x, y2 - y). What matters is that the pack treats the second pair as an exclusive end - the right and bottom numbers are the first pixel outside the box, the same convention as Python slices and OpenCV rectangles. Half the off-by-one crops in the ecosystem come from someone assuming inclusive coordinates, so pick a convention, notice which one your source uses, and convert.

The node also refuses to do anything stupid. It requires exactly four numeric values and rejects booleans; converting from xywh it errors if width or height is negative; converting from xyxy it errors if the box is reversed (x2 < x1). Core's mask tools take a reversed rectangle and quietly produce nothing useful, so the noisy failure is a feature.

When you actually reach for it

You reach for it when two halves of your workflow came from different eras. A typical case: a detector gives you xyxy boxes, and you want to feed core's crop-and-paste machinery, which is built around x, y, width, height. Convert once at the seam, keep the rest of the graph consistent.

The reverse case is just as common. You have a box from a core node and you want to write it into a SEGS entry, a mask region, or anything else in Impact's dialect. Convert to xyxy and it lines up with the rest of the SEGS metadata - crop_region, bbox, and the coordinates in a detailer's output all speak xyxy.

Output is a single plain BBOX value, not a list, so nothing downstream re-executes on your behalf. If you are holding a collection or a list of boxes, convert after unpacking it - BBOX Collection to List first, then this node per box.

Install

The node is part of ComfyUI-Utility-Suite. ComfyUI Manager → search ComfyUI-Utility-Suite → install → restart, or:

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

Restart ComfyUI. There is nothing to download: no models, no checkpoints, no detector weights. The only declared dependency is opencv-python-headless, and even that is not needed by this particular node. The pack is written against ComfyUI's newer V3 node API (comfy_api.latest), so you need a recent backend - the classic symptom on an old install is that the whole pack silently fails to import.

Traps

One box at a time. This is a scalar converter. Hand it a list and it will not map over it; you get a type error about expecting exactly four numeric values. That is the pack being honest rather than helpful.

No clamping. A box that runs off the canvas, or has a negative origin, passes through untouched. The error surfaces later, in whichever crop node you wired it to, and it will look like that node's fault.

No auto-detect. The dropdown is manual. If you flip it the wrong way you get a box roughly the size of its own offset, which is the failure mode that convinced you to read this page. If the result looks "shifted by about the size of the box", you have your answer.

The exclusive end is not a detail. If you are converting boxes you intend to hand to a mask-drawing or crop node, confirm which convention it wants; a one-pixel shift is invisible until you spot the seam.