KpsScale
Resizing keypoints to match a target canvas
- kps_data
- kps_data
A small, purely mechanical node: give it kps_data and a target width/height, and it rescales the keypoints to fit that new canvas size. This is the counterpart to resizing a pose image - if PreprocessImage (or anything else in your graph) resizes your photo to, say, 1024×1024, and you're maintaining keypoints separately rather than letting that node generate the control image for you, you need this node to keep the two in sync.
What "scale" means here specifically
This node targets an absolute destination size, not a multiplier. You're saying "make this keypoint set fit a canvas of exactly this width and this height," and it does the proportional math to get there. That's the key difference from its sibling, KpsScaleBy, which instead takes a relative zoom factor (1.5 = 150% bigger, wherever that lands). If you know the exact pixel dimensions you're targeting - which is the common case, since SDXL wants specific resolutions - this is the more direct node to reach for.
The inputs and outputs that matter
kps_data- required, from any upstream KPS source.width/height(both default 1024) - the target canvas size the keypoints should be scaled to fit.
Output: kps_data, rescaled.
Where this fits
Same family of problem as KpsCrop: whenever a pixel-space transformation happens to your pose image independently of what this pack's own detection nodes handle automatically, any keypoint data you're carrying alongside it needs the matching transformation applied, or the control image built from those keypoints will describe a different scale than the actual pose image. PreprocessImage's new_width/new_height outputs are the natural values to feed in here if you're tracking a resize it performed.
Install
ComfyUI Manager: search comfyui-instantId-faceswap. Manual: git clone https://github.com/nosiu/comfyui-instantId-faceswap into custom_nodes/, pip install -r requirements.txt. No model dependency - this is coordinate math, nothing InstantID- or insightface-specific about the computation itself.
Common issues & troubleshooting
Face proportions look stretched, not just resized. If your target width/height doesn't preserve the original aspect ratio of the keypoint set, you'll get non-uniform scaling - the face gets squashed or stretched rather than scaled cleanly. If aspect ratio matters to you, make sure your target dimensions match the source's proportions, or accept the distortion if you're deliberately going for that.
Generated control image doesn't line up with the pose image. Usually means this node's target size and the actual resize applied to the pose image (elsewhere in the graph) don't match. Trace both back to make sure they're using the same numbers - a mismatch here is silent; nothing errors, it just conditions on geometry that doesn't correspond to what's in the frame.
Unsure whether to use this or KpsScaleBy. Use this node when you know the exact target dimensions (matching a specific resize elsewhere in your graph). Use KpsScaleBy when you're thinking in terms of "bigger" or "smaller by some factor" rather than a specific pixel size.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| kps_data | KPS_DATA | — | |
| width | INT | 10240–16384 | — |
| height | INT | 10240–16384 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| kps_data | KPS_DATA | — |