Nodes/comfyui-easy-sam3-tools/Convert PoseData -> PosePoint (OpenPose Editor)
ComfyUI Node

Convert PoseData -> PosePoint (OpenPose Editor)

Your pose data won't plug into the OpenPose Editor? This is the adapter.

By SuLU-K·Created 9 months ago·Updated 7 months ago· 9
Convert PoseData -> PosePoint (OpenPose Editor)
  • pose_data
  • pose_point

Pose editing in ComfyUI runs on a couple of de-facto standards, and they don't talk to each other. The DW Preprocessor and the OpenPose-editor family emit POSE_KEYPOINT - a list of people, each with an 18-joint COCO skeleton flattened into (x, y, confidence) triples plus a canvas width/height. Some detection nodes, though, hand you a different blob, POSEDATA, with the keypoints tucked inside a pose_metas-style dict. Drop one into the other and you get a red wire, or worse, a node that runs and then throws. ConvertPoseDataToPosePoint exists to bridge exactly that gap.

It's a pure format adapter. You feed it pose_data (the only input, POSEDATA, required), and it returns pose_point (POSE_KEYPOINT). Nothing is detected here - if you don't already have a POSEDATA-producing node upstream, this node has nothing to convert. Its own docstring names the intended source as a "PoseAndFaceDetection"-style node; whatever that is in your workflow, it's the thing that actually runs pose inference.

How the conversion works

The node reads the pose_metas_original list out of your pose data (falling back to pose_metas if the first key is missing), then walks each meta's keypoints_body. Each keypoint's raw pixel coordinates get normalized to 0–1 against the detection canvas size, and written into the OpenPose flat array - 18 joints × (x, y, confidence) - with missing joints left at zero. The output keeps the per-person structure the editor nodes expect: canvas_width, canvas_height, and a people array holding pose_keypoints_2d. It's the same shape space-nuko's OpenPose Editor and the DW Preprocessor emit, so anything downstream that eats POSE_KEYPOINT (pose editors, Lip Mask from Pose Keypoints-style mask nodes) will accept it.

What you actually set

One input, one output, nothing to tune:

  • pose_data (POSEDATA) - wire this from your pose detection node.
  • pose_point (POSE_KEYPOINT) - feed it into whatever wanted the editor format.

That's it. No widths, no confidence thresholds, no mode dropdowns. The node either converts or raises.

Installing it

This pack rides along with the rest of the easy-sam3-tools set, so the install is the pack install:

  • ComfyUI Manager → search comfyui-easy-sam3-tools → Install → restart.
  • Or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/SuLU-K/comfyui-easy-sam3-tools

Then restart ComfyUI. There's no requirements.txt and no model download - the converter only needs numpy, torch, and Pillow, which ComfyUI already ships. The node shows up under Test Nodes/Pose, and like everything else in this pack the "Test Nodes" prefix is honest about its provenance: it's a personal utility that got published, not a polished product.

Where people get burned

  • It fails at run time, not at wiring. Custom types in ComfyUI are stringly-typed, so the red wire doesn't always appear. The errors - "pose_data has no pose metas to convert" or "failed to convert pose metas into POSE_KEYPOINT format" - show up when you hit Queue, and both mean the upstream node's output didn't have the structure it expected (no detections, or a different dict layout than pose_metas_original/pose_metas).
  • Normalized vs. pixel coordinates. The converter normalizes to 0–1, which is what the editor format wants. If your downstream assumes raw pixels, the pose will render scrunched into a corner - that's expected behavior, not a bug.

If you're hitting a shape mismatch, check what your detection node actually emits before blaming the converter. Nine times out of ten the fix is a different upstream node, not this one.

CategoryTest Nodes/Pose

Inputs (1)

NameTypeDefaultDescription
pose_dataPOSEDATA

Outputs (1)

NameTypeDescription
pose_pointPOSE_KEYPOINT