Convert BBox to X Y Width Height

This one's the mirror image of this pack's KY_BBoxPosition, which takes four raw integers and packages them into a BBOX. This node does the opposite: it takes a BBOX object and hands you back the four plain integers it's made of. Simple, one job, does it and nothing else.

Why you'd want raw numbers back out of a box

A BBOX is convenient to pass around as a single wire between detection and crop nodes - that's the whole point of the type. But sometimes you need the individual numbers: to do math on the width before feeding it somewhere else, to log them, to feed X/Y into a text overlay, or to compare a box's dimensions against a threshold with a math node like this pack's own KY_MathExpression. Whenever a BBOX hits a wall where the next node wants scalars instead of a bundled object, this is the node that bridges it.

Inputs and outputs

One required input: bbox, typed BBOX, with no default (null) - meaning you always need something wired in here, this isn't a node you can leave disconnected and expect a sane fallback.

Four outputs, straightforward: X, Y, Width, Height, all plain INT. No rounding options, no offset, no scaling - just unpacked numbers exactly as they came out of the box.

Installing it

ComfyUI Manager: search ComfyUI-KYNode, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/yorkane/ComfyUI-KYNode

Restart ComfyUI. Nothing to download - this is arithmetic on a data structure, no models, no binaries.

Common issues

Since bbox has no default value, the most likely first error is simply not having anything wired into it - the schema shows null as the default, and a BBOX type socket with nothing connected typically fails at graph validation rather than silently producing zeros.

The bigger, less obvious trap is the same one that comes up across this whole pack's BBox family: BBOX isn't a rigidly standardized type across the ComfyUI ecosystem. It's a loose convention, and different pack authors implement the underlying tuple/list slightly differently - some as (x1, y1, x2, y2) corner coordinates, others as (x, y, w, h). This node's name and output labels (X, Y, Width, Height) tell you what it assumes the incoming BBOX represents. If you're feeding it a box from a detector node in a different pack entirely, double-check that pack's own convention actually matches - if it doesn't, you'll get four numbers that parse fine but describe the wrong rectangle, and nothing in this node will warn you, since it has no way to know the box came from somewhere with a different convention.

Staying within this pack sidesteps that entirely: boxes built by KY_BBoxPosition, KY_JSONToBBox, or KY_CreateMask's bboxes inputs are far more likely to be shape-compatible with what this node expects to unpack, since they all come from the same author.