Crop By Bounding Boxes

This one's for when you're not hand-picking crops. Feed it an image and a set of bounding boxes - from a face detector, a pose estimator, a grounding model, wherever - and it crops each region and hands you all of them stacked into one image batch, resized to a uniform output size. It's the "crop everything a detector found" node.

It's an experimental built-in (ships with ComfyUI core, no install), and it lives alongside the pose/keypoint nodes, which tells you who it's aimed at: pipelines that detect regions and then want to run something on each one.

How it works

You wire in an IMAGE and a BOUNDING_BOX input. That bbox input is forced - you can't type a value into it, you have to connect a box source, and in ComfyUI a bounding box is its own little object type produced by nodes like the Bounding Box primitive or face/pose detectors. If it's not obvious where to get one, search "Bounding Box" in the node menu.

Then the geometry:

• padding (0–1024) - extra pixels added on all four sides of the box before cropping. This is the knob you'll actually move. Detection boxes hug their subject tight, and a crop with zero padding cuts off the context - the grounding-to-crop workflows in the community pad by 50px or so on purpose.
• output_width / output_height (default 512, min 64, step 8) - each crop is resized to exactly this. Step of 8 again means "keep it latent-friendly."
• keep_aspect - stretch (default) squashes the crop to fill the output size; pad letterboxes with black instead, preserving the aspect ratio. Use pad when you don't want faces squished but the downstream step still demands a fixed size.

A detail that surprises people: multiple boxes on the same frame are unioned into one crop region, not cropped individually per box. And it's frame-aware - give it a video batch and it pulls the bbox list per frame (repeating the last list if you run out). The output is all crops concatenated into a single batch, so downstream you'll often want to split the batch or process it as one.

Why it exists

The intended pipeline is detection-first: SDPoseFaceBBoxes → CropByBBoxes → some per-face step → stitch back. It's the crop stage of a "detect, crop, process, paste" loop - the same shape as FaceDetailer's internals, just exposed and manual. The modern variant that's been circulating since 2025 is text-grounded: a VLM names an object, you take its bounding box, pad it, and crop exactly that region to run an edit on. This node is the "take the box and crop it" half of that trick.

Where it bites

• Forgetting padding. Raw detector boxes are brutally tight - the classic example is a box that wraps the cup but not the saucer. Without padding, your crop is useless.
• The union surprise. Expecting one output per box and getting one combined crop per frame instead. Design around it.
• Empty or degenerate boxes fall back to a center crop rather than erroring - which is friendly, but means a "working" workflow can silently be cropping the wrong thing if your detector outputs nothing.
• stretch distortion. For faces and anything with recognizable proportions, pad looks far better than stretching a 0.7-aspect crop into a square.

If you're hand-picking single crops, the plain ImageCropV2 is simpler. This node is for when the boxes come from somewhere else and there are a lot of them.