Draw BBoxes

Every detection node in this category hands back bounding boxes, and boxes are great - until you realize you can't see them. A list of {x, y, width, height} coordinates tells you almost nothing about whether your detector is finding the right things. This node is the visualization layer for the whole detection family: feed it a BOUNDING_BOX (plus the original image) and it draws the rectangles right on top, labels and confidence scores included. It's the "are my boxes right?" node, and in a debugging-heavy ecosystem that makes it quietly essential.

Because boxes are a shared currency across the category, this one node serves almost every other node in the group. RTDETR_detect, SAM3_Detect's bboxes output, MediaPipeFaceLandmarker's bboxes, SDPoseFaceBBoxes - they all emit the same BOUNDING_BOX type, and they all plug into DrawBBoxes for a visual check. If you're about to feed boxes into a crop, a detailer, or a filter, spending one node to look at them first catches most of your mistakes before they cost you a generation.

How it works

It's deliberately simple: for each frame in the batch, it draws each box as a rectangle on the image using PIL, labels it with the box's class label (it recognizes the COCO labels that RT-DETR produces), and stamps the confidence score next to it. Detections that arrive as a flat list get applied to every image in the batch; per-frame lists map to per-frame images. If you leave the image input unconnected, it builds a black canvas sized to fit the boxes - which is genuinely useful when all you want is a clean diagram of detections.

The inputs and outputs that matter

• bboxes - the BOUNDING_BOX input. Required. This is the only thing you must connect.
• image - optional. The frames to draw on; without it, you get the black-canvas diagram.

The out_image output is the annotated image, batch-aligned with your input - drop it into a preview or save node.

What trips people up

The box coordinates are expected in the same coordinate space as the image you're drawing on. If a detector output boxes in its own internal resolution (some crop-first pipelines do), the rectangles land in the wrong place and you'll swear the node is broken - it isn't, the boxes just don't match the image. Also, an empty detection (no boxes for a frame) isn't an error; you get the frame back with nothing drawn, which is the correct behavior but easy to misread as a skipped frame.

And a design note so you don't fight it: this node draws on the image - it does not crop, does not filter, and does not change the boxes. Pair it with a crop-by-bbox node when you want to actually extract what the boxes found. It's the eyeball step, not the hand step, and it does that one job well.