KoO Crop Data Unpack

.cube files and prompts are easy to pass around a graph. Rectangles are not. The moment a node hands you a crop as a single opaque KOO_CROP_DATA object, everything downstream that wants "the width" is stuck - unless you crack it open.

KoO Crop Data Unpack does the cracking. One typed input, nine plain outputs, no settings, no UI. It's the smallest node in this article set and probably the one you'll add to the most workflows.

What feeds it

KOO_CROP_DATA is a custom socket type produced by KoO.Load Image & Crop Next (the "Next" loader, not the older KooLoadImageCrop in the same pack - that one outputs individual integers directly). The Next loader returns IMAGE, MASK and one crop_data bundle carrying the geometry it settled on after snapping to whatever crop ratio you picked.

The unpack node is a pure reader. It accepts the dict, pulls keys out with defaults, and emits them. If someone hands it something that isn't a dict it returns zeros rather than throwing, which is polite in a graph and a bit rude when you're debugging - an all-zeros output usually means the wire upstream is dead, not that your crop is 0×0.

The outputs

Nine, in this order:

• crop_x, crop_y - top-left corner of the crop in source-image pixels.
• crop_width, crop_height - the crop's size in pixels.
• original_width, original_height - the file's real dimensions, before cropping.
• cropped_width, cropped_height - the dimensions after any optimisation pass the loader applied.
• ratio - a STRING label for the crop ratio that was used (Free, 4:5, Custom, etc.).

Where these actually earn their place: feeding crop_width/crop_height into your resolution planner so the generation matches the crop instead of getting letterboxed; feeding original_width into a conditional that picks a different upscale path for portrait vs landscape; stuffing the whole set into filename templates so a batch of crops from one shot stays identifiable; and passing the crop rectangle back out to a paste/composite step so you can stitch the result into the original frame. That last one is where the pair really matters - the crop is lossless only if you remember where it came from, and a KOO_CROP_DATA object is a much better carrier than four loose integer wires that someone eventually re-routes wrong.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/kevintronchin-blip/koo-nodes-pack

Restart ComfyUI. Requirements are the four things ComfyUI already ships (torch, numpy, Pillow, aiohttp) - nothing to pip install, nothing to download. The node lives under KoO Tools / Image, next to both crop loaders.

One structural caveat: this node is useless on its own. KOO_CROP_DATA is a pack-local type, so the only producer in a stock install is the KoO loader. If you're already using core Load Image plus a separate crop node, this pair isn't your answer - the unpack solves a problem the pack deliberately creates by bundling crop geometry.

Registry listing at v1.0.3 is pending moderation approval, so Manager search may return nothing. The README's route: download the source ZIP, extract to ComfyUI/custom_nodes/koo-nodes-pack, with __init__.py directly in that folder.

Troubleshooting

Can't find KOO_CROP_DATA in the type list. You're looking for a socket that doesn't exist until the loader node is loaded, or you have an older KoO install that lacks KoO_LoadImageCropNext. Check for duplicate or stale KoO folders first - the pack's troubleshooting section names duplicate IDs as the first suspect for missing-node symptoms.

All zeros. The upstream crop wasn't confirmed. Both crop loaders in this pack gate the crop on a confirmation flag set by the on-canvas crop UI, and if you never confirmed, the loader passes the full image and the metadata describes a full-frame crop. Not a bug, but a genuinely confusing result the first time.

ratio is Free. You didn't constrain the aspect, so the numbers are whatever you dragged. Fine for compositing, useless if you wanted a 4:5 portrait. Set the ratio on the loader, not here - this node can't change anything.