ValueError due to Keypoint Mismatch (18 vs 17) & Inquiry about Checkpoints

[seoyeonmmn]

Hello, thank you for your impressive work on GPGait/GPGait++ and for sharing the code.

I am currently trying to train GPGait/GPGait++ using the OUMVLP-Poss dataset.
However, I encountered a shape mismatch error.

ValueError: could not broadcast input array from shape (17,3) into shape (18,3)

It seems that the error is caused by the discrepancy between the number of keypoints in the dataset (18 keypoints, AlphaPose format) and the model/code expectation (17 keypoints, COCO format).

In the GPGait paper, it is mentioned:

"For OUMVLP-Pose, the sequences are generated by AlphaPose [7] consisting of 18 keypoints for each frame. In our experiments, we transform the keypoints into the COCO2017 format with 17 keypoints for the cross-domain evaluation."

However, I checked the data loading code and could not find the implementation for this specific transformation (18 -> 17 keypoints). It seems the code attempts to process the data without converting the format, leading to the broadcast error.

Question & Requests

1. Missing Keypoint Transformation Could you advise on how to handle this mismatch?

• Is there a specific preprocessing script or a flag I missed that handles the 18-to-17 conversion?
• If not, could you share the code snippet used for this transformation in your experiments?

2. Pretrained Checkpoints I noticed that releasing model checkpoints is on the TODO list (or commonly requested).

• Could you provide the pretrained checkpoints (.pth or .ckpt) for GPGait++?
• Having the checkpoints would be extremely helpful for verifying my environment and reproducing the results reported in the paper.

Thank you in advance for your help!

[DreamShibei]

Hi, you can find the preprocessing code for OUMVLP-Pose here: ReadMe | Code.

As for the checkpoint, we will release it soon. Please stay tuned!

[seoyeonmmn]

Thank you for the guidance! I was able to resolve the shape mismatch issue using the preprocessing code you mentioned.

However, I am currently facing a reproducibility issue.
I evaluated the official checkpoint provided and also tried retraining from scratch using the default config, but in both cases, the performance is lower than the results reported in the paper.

Could you please advise if there are specific environment settings or evaluation protocols I might be missing? Sharing a training log for comparison would also be very helpful.

[DreamShibei]

Could you please provide the model and the results you obtained? I'd be happy to take a look and help.

[seoyeonmmn]

Thanks for your help!

I have uploaded the retrained model(GPGait) and the test logs to the link below:
https://drive.google.com/drive/folders/1YM1zbie_55tKYmRnolr3ZY1frQ6CA07n
Google Drive - FastPoseGait (1) > FastPoseGait-Vanilla (1) > GPGait (1) > gpgait-oumvlp-60.pt

Below is the terminal log from my test with the official checkpoint, showing the performance gap:

[2025-11-24 16:57:50] [INFO]: -------- Test Pid List --------
[2025-11-24 16:57:50] [INFO]: [00002, 00004, ..., 10307]
[2025-11-24 16:57:52] [INFO]: Total Sequences: 134211
[2025-11-24 16:57:58] [INFO]: Restore Parameters from /home/seoyeon/FastPoseGait/checkpoints/gpgait-oumvlp-60.pt !!!
[2025-11-24 16:57:58] [INFO]: Parameters Count: 32.47901M
[2025-11-24 16:57:58] [INFO]: Model Initialization Finished!
Transforming: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 134211/134211 [26:39<00:00, 83.89it/s]
[2025-11-24 17:25:14] [INFO]: ===Rank-1 (Exclude identical-view cases)===
[2025-11-24 17:25:14] [INFO]: NM@R1: [5.44 15.65 35.24 49.95 55.15 52.01 45.79 36.84 47.69 53.81 64.20 64.18
 58.98 54.12]
[2025-11-24 17:25:14] [INFO]: NM@R1: 45.65%

[DreamShibei]

Are the keypoints you downloaded from the official source AlphaPose or OpenPose? Our model was trained using the AlphaPose estimator.

[seoyeonmmn]

Yes, I am using the official OUMVLP-Pose dataset.
I downloaded it directly from the official source. http://www.am.sanken.osaka-u.ac.jp/BiometricDB/GaitLPPose.html

I haven't modified the original dataset files. Since the data source seems correct, I suspect the issue might lie elsewhere (e.g., preprocessing or environment).

[DreamShibei]

Could you confirm if you are using the estimation results from the official open-source AlphaPose? Since our model was trained on AlphaPose detections, using OpenPose results for testing will indeed cause a performance drop.