Crop Image Pipe (JPS)
Unpack your crop settings back into individual wires
- cropimage_settings
- source_crop_pos
- source_crop_offset
- support_crop_pos
- support_crop_offset
- crop_intpol
Pairs with Crop Image Settings (JPS). That node bundles crop configuration for a source and a support image into one wire; this one takes the bundle apart again, dropped wherever downstream you actually need the individual values. It's the standard Settings/Pipe split this pack uses everywhere - build the menu once, unpack it near where it's consumed, even if that's a different corner of a large graph.
What comes out of it
One input, cropimage_settings - a BASIC_PIPE (JPS's own bundle type, a plain tuple, not Impact Pack's object despite sharing the type label). Five outputs:
source_crop_posandsupport_crop_pos- the crop anchor (center/top/bottom/left/right) for each of the two images, feeding whichever crop nodes are actually doing the work on your source and support images respectively.source_crop_offsetandsupport_crop_offset- the pixel-offset fine-tune for each anchor.crop_intpol- the shared interpolation method (lanczos, nearest, bilinear, bicubic, area, nearest-exact) both crops use.
This node performs no cropping itself. It's routing between your settings menu and whatever image-crop nodes are actually processing the source and support images elsewhere in the graph.
The source/support pairing this node is built around shows up across the pack - the ControlNet Settings nodes (OpenPose, CannyEdge, MiDaS) all let you pick between a "Source Image" and a "Support Image" as the actual ControlNet reference, so this crop pair is naturally the node you'd reach for to prep both candidate images identically before either one gets selected downstream. For ordinary photographic references, lanczos (the pack's usual default choice on other crop nodes) is a safe pick; switch crop_intpol to nearest only if what you're cropping is already a computed map with hard-edged, non-continuous values - a mask or a pre-rendered pose skeleton, say - where a blending interpolation method would smear pixels that need to stay crisp.
This node has no width, height, or target-size output of its own - unlike Crop Image Square (JPS), which explicitly resizes to a square target, this pair is purely about positioning within whatever dimensions the downstream crop node already works to. That makes it the right tool when you're aligning two images against each other (a source and a support reference feeding the same downstream step) rather than forcing either one to a specific new size.
Installing it
Ships with the rest of the pack. ComfyUI Manager: search JPS Custom Nodes for ComfyUI, install, restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/JPS-GER/ComfyUI_JPS-Nodes.git
Restart afterward, and delete any earlier copy of the pack first. No models or extra dependencies - this is pure logic.
Where people get tripped up
Without a Crop Image Settings (JPS) node upstream, this one has nothing to unpack - it's not a standalone tool. And because it outputs settings for two separate images (source and support), it's easy to wire one pair correctly and forget the other, especially if your workflow only actually uses one of the two images downstream - double-check both pairs of outputs actually connect to something before assuming the crop is applying where you expect.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| cropimage_settings | BASIC_PIPE | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| source_crop_pos | center,top,bottom,left,right | — |
| source_crop_offset | INT | — |
| support_crop_pos | center,top,bottom,left,right | — |
| support_crop_offset | INT | — |
| crop_intpol | lanczos,nearest,bilinear,bicubic,area,nearest-exact | — |