peaks[part_idx] list index out of range

[HoangTienDuc]

Hi @ganler. Thanks for your awesome work. I use your openpose coco 368x656 tensorrt model to get human pose. I am very happy when i tested tried your hyperpose openpose coco 368x656, the speed and acc is very good. So, i want to create a python script to read your tensorrt coverted model and make prediction. Base on your sample code, I think i got right heatmap.

To get pose keypoints, I followed your postprocessing. But i stuck in your process_paf.

list index out of range
  File "/data/Openpose_trt/hyperpose/Model/openpose/processor.py", line 84, in process_paf
    peaks[part_idx].append(Peak(peak_idx,part_idx,peak_y,peak_x,peak_score))
  File "/data/Openpose_trt/hyperpose/Model/openpose/processor.py", line 59, in process
    humans=self.process_paf(peak_map[0],conf_map[0],paf_map[0])
  File "/data/Openpose_trt/openpose_infer.py", line 181, in <module> (Current frame)
    humans=postprocessor.process(conf_map[0],paf_map[0], 368, 656)

In coco dataset, we have only 19 positions in total (self.n_pos). But the tensorrt output give us 38.

trt outputs:

0:'output_paf:0': (1, 38, 46, 82)
1:'output_conf:0': (1, 19, 46, 82)

So i got below error:

peaks[part_idx] list index out of range

Inference code (base on your infer.py)

Hope to get a help from you. Thank you!

[Gyx-One]

Hello! @HoangTienDuc Sorry to response so late. Solution: you can directly use python_demo.py code which is added on the latest commit merged. python_demo.py is a correct version of the old infer.py and also demonstrate the usage of modulized processors :). (remember to update your code to the newest version of hyperpose so you won't meet API compatibility issue.)

Why this issue happen: 1.The trt output tensor shape is correct We do have 19 channels over the conf_map, each one for a human body joint, and we also do have 38 channels over the paf_map, because in openpose setting, we use 19 limbs(including virtual limbs) to connect the joints, and each limb contains its x coordinate map and y coordinate map, and thus lead to 38 channels :).

2.The issue is due to the channel format(NCHW or NHWC) I found this issue is due to the version compatibility. We used to support both NCHW and NHWC channel format and this lead to some confuse between difference channel format in post-processing. Thus I unifrom all the processing logic to be NCHW(channels_first) format in the newest commit and add a corrected demo code at python_demo.py (which is tested to make sure it can work with the existing model weights)

Thanks for using our library.