Crop Image by bbox
The detector-driven half of the crop pair
- bbox
- image
- IMAGE
This is the other half of this pack's crop pair. KY_CropImageByXYWH wants four numbers you already know; this one wants a BBOX object - the kind of thing a detector node, KY_BBoxPosition, or KY_JSONToBBox hands you - and crops the image to it directly. Deliberately minimal: two required inputs, one output, no extra knobs.
Where it fits
This is the "crop" step of the detect-crop-refine loop that Impact Pack's FaceDetailer automates end to end in one node: something finds a region (a face detector, a hand detector, a bounding box parsed out of a vision-LLM's JSON response), that region becomes a BBOX, and this node cuts it out of the source image so you can process just that piece - resample it, upscale it, run it through a different model - before compositing it back. The value of doing it as separate manual nodes instead of an all-in-one detailer is that you can insert your own logic in between: a size check, a filename-based decision, a conditional skip.
Inputs and output
Two required inputs: bbox (typed BBOX) and image (typed IMAGE). One output: the cropped IMAGE. That's the entire node - no padding, no rounding, no bounds parameters. If you need the crop's size adjusted to a clean multiple for your model's VAE (the divisible_by behavior that KY_CropImageByXYWH has), you need to bake that into the box before it reaches this node, not after.
Installing it
ComfyUI Manager: search ComfyUI-KYNode, install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/yorkane/ComfyUI-KYNode
Restart ComfyUI. No external dependencies - plain tensor slicing given a box.
Common issues
The most common failure crossing packs is a shape mismatch: BBOX isn't a rigidly standardized type across the whole ComfyUI ecosystem, more of a loose convention that different pack authors implement slightly differently. A detector from a different pack entirely might emit something this node doesn't parse the way it expects. The safest bet, if you're staying within this pack, is to build your BBOX with KY_BBoxPosition or KY_JSONToBBox - both come from the same author and are far more likely to be shape-compatible with this crop node than a box pulled from an unrelated pack.
There's no bounds-checking here - if your box pokes outside the image's actual dimensions, that has to be handled upstream (in whatever produced the box), since this node has no parameters to clamp or validate it.
And since it takes no rounding parameter, if you're feeding the crop straight into a sampler and getting VAE artifacts at the edges, the fix is upstream - round your box's width/height to your model's required multiple (8, 16, 32, or 64 depending on the family) before it reaches this node, not after.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| bbox | BBOX | — | |
| image | IMAGE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |