Image_Solo_data

Image_solo_crop/Image_solo_crop2 package everything they know about a crop - its position, its size, its scale - into one opaque stitch bundle so Image_solo_stitch can paste the result back later without you re-deriving any of that math. Image_Solo_data is the node for when you don't want the automatic paste-back - you want the raw numbers themselves, exposed as plain outputs you can route into math nodes, conditional logic, or a debug display.

How it works

It's a pure decoder: one input, seven outputs, no image processing happening at all. Plug in a stitch bundle and it reads off the crop's valid region size, its offset within the original frame, the original frame's full dimensions, and the scale factor that was applied. There's nothing to configure - the node has exactly one input and it either has a valid stitch to read or it doesn't.

The inputs and outputs that matter

• stitch (STITCH2, required) - the bundle from Image_solo_crop or Image_solo_crop2. This is a pack-specific type distinct from Image_Resize_sum's STITCH3 bundle - the two are not interchangeable, and the graph simply won't let you wire one into the other's slot.

Seven outputs, all INT except the last:

• valid_width / valid_height - the size of the actual cropped region.
• x_offset / y_offset - where that region sits within the original full frame.
• full_width / full_height - the original frame's total dimensions.
• scale_factor (FLOAT) - the scale that was applied during the crop, if any.

Why you'd use this instead of Image_solo_stitch

Image_solo_stitch does the paste-back for you, blend controls and all - that's the node to reach for 90% of the time. Image_Solo_data is for the other 10%: cases where you need the raw geometry to feed something that isn't a straightforward paste. Building a custom compositing chain, driving a downstream crop or mask node with the same offsets, or just wiring the numbers into a debug/text node so you can see what the crop actually did while you're building a graph - all cases where you want the numbers, not the automatic behavior.

How to install it

ComfyUI Manager: search ComfyUI-Apt_Preset, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/cardenluo/ComfyUI-Apt_Preset
pip install -r requirements.txt

install.bat is Windows-only; on Linux (comfy.icu's executor included) run pip install -r requirements.txt directly. This node does no image work at all, so there's nothing to download for it specifically.

Common issues

The main failure mode is a type mismatch, not a bug: this node only accepts STITCH2, which only Image_solo_crop and Image_solo_crop2 produce. If you built your crop with the Image_Resize_sum family instead, its bundle is STITCH3 and belongs with Image_Resize_sum_data, not this node - the wire won't connect if you try to cross them, which is ComfyUI telling you the types don't match rather than an error to chase down.

Otherwise there's little to go wrong here - it's arithmetic on a bundle, not image processing. If the numbers look off, the more likely place to look is the upstream crop node's settings (crop mode, expand margins, scale) rather than this decoder.

As with every node in this pack, it lives inside a large suite whose requirements.txt covers a lot more than image cropping (onnxruntime, gguf, transparent-background, scenedetect, and more, for the pack's other 100+ nodes) - all of which has to import cleanly for ComfyUI-Apt_Preset to load at all. There's a documented case of a fresh install failing with IMPORT FAILED; if that happens, the real cause is printed in the ComfyUI console above the generic failure line.