Extract Crop Data from Batch

Salt's crop-and-paste pipeline bundles per-image crop geometry into a single custom type, CROP_DATA_BATCH, so it can travel through your graph as one wire instead of a pile of separate numbers. That's convenient right up until you need to actually see or use one specific image's coordinates - which is exactly what SaltBatchCropDataExtractor is for.

What it does

Two inputs: crop_data_batch, the bundled batch, and index (integer, minimum 0), which picks a single entry out of that batch by position. What comes back is that one crop's geometry unpacked into plain integers: width, height, top, left, right, bottom. There's also a crop_data_batch output that simply passes the original batch through unchanged - useful because it lets you insert this extraction node into a chain without breaking the pipe that carries the full batch onward to wherever it actually needs to go, like this pack's SaltImagePasteCrop.

Where you'd use this

Two real scenarios. First, debugging: if a crop-and-paste result looks wrong for one specific image in a batch, pulling its exact top/left/right/bottom values out with this node lets you actually see the numbers instead of guessing at what the bundled crop data contains. Second, bridging: if you need those crop coordinates as plain integers for something that doesn't understand Salt's CROP_DATA_BATCH type - feeding a coordinate into a math node, or into any other node in your graph built around ordinary INT inputs rather than this pack's custom type.

Installing it

ComfyUI Manager: search SaltAI-Open-Resources. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/get-salt-AI/SaltAI

Restart ComfyUI. No dependencies beyond the pack itself - this node is just unpacking data that already exists upstream.

Common issues

The obvious failure mode is an index that's out of range for the batch you're pulling from - if your batch has ten crops and you ask for index 12, expect an error rather than a silent fallback. Count your batch size before hardcoding an index, or drive the index dynamically from wherever your batch size is already known in the graph rather than guessing. Beyond that, this node doesn't do anything to the data - it's a pure unpack, so if the numbers look wrong, the bug is almost certainly upstream in whatever generated the crop_data_batch in the first place, not in this extraction step.