Wan Pose Format Convert — OP18 → BODY-25 / COCO-17 / MP-33 (V2)

The V2 preprocessor stores body keypoints in OpenPose-18 topology. A lot of downstream consumers don't want that. WanPoseFormatConvertV2 re-emits the same pose_data in another skeleton format - BODY-25, COCO-17, or MediaPipe-33 - and additionally emits a standard ComfyUI POSE_KEYPOINT list, which is exactly what OpenPose-style ControlNet preprocessors expect. No re-detection, no model, no heavy compute: it's a geometric remap of landmarks you already have.

This is a bridging node, and it exists because the ecosystem splits along topology lines. The KB context is worth knowing: OpenPose itself defined 18-keypoint body detection, then grew to BODY-25 (adding mid-hip and toe/heel landmarks), while most modern detectors (HRNet, RTMPose, Sapiens, ViTPose-COCO) emit COCO-17, and MediaPipe Pose uses 33. If the ControlNet or animation tool you're feeding expects one of those and you've got OP-18, you'd otherwise be hunting for a converter or re-running detection with a different model. This node closes that gap in one hop.

How it works

The conversion is pure remapping because of a happy structural fact: OpenPose-18 is a strict subset of both BODY-25 and MediaPipe-33, and its points rearrange into COCO-17. So the node can map landmarks without inventing anything. Landmarks the source genuinely can't supply - toes, mouth corners, inner-eye points, that sort of thing - are written as None, and downstream nodes decide whether to discard or impute them. It's honest about what it doesn't know, which is the right design.

Every output meta gets an extra keypoints_body_<format> key alongside the original keypoints_body, plus a bundle-level body_format string recording what was done.

Inputs and outputs

• pose_data - the OP-18 bundle from the V2 preprocessor (or the standalone detector).
• target_format - body_25, coco_17, mediapipe_33, or openpose_18 (passthrough). The display name spells out the whole menu.
• use_metas - edited (default) or original. Whether to convert from the edited pose_metas or the raw pose_metas_original. If you've edited the pose and want the edits preserved in the conversion, leave it on edited.
• emit_face / emit_hands - both default true; whether the face and hand keypoints ride along in the converted output.

Outputs: pose_data (the converted bundle), pose_keypoint (the standard POSE_KEYPOINT that plugs straight into OpenPose ControlNet preprocessors), and an info summary.

The honest take

Two notes. First, the COCO-17 output is the most broadly useful - it's the modern default topology, so if you're feeding a pose ControlNet that isn't explicitly OpenPose-era, COCO-17 is the safer bet. Second, remember the conversion carries the source's errors. If ViTPose gave you a shaky wrist, it's a shaky wrist in BODY-25 too - format conversion fixes topology mismatches, not detection quality. Wire this after the standalone WanPoseDetectViTPoseV2 (or the main detector) and before anything that insists on a specific skeleton layout, and it'll quietly unblock half your integration problems.

Install is the shared pack path: ComfyUI Manager search "WanAnimatePreprocessV2", or git clone https://github.com/Code2Collapse/ComfyUI-WanAnimatePreprocessV2 + pip install -r requirements.txt + restart. No models of its own.