human-pose-estimation.pytorch
human-pose-estimation.pytorch copied to clipboard
PCK
Dose anyone know why divided by 10 here: https://github.com/microsoft/human-pose-estimation.pytorch/blob/18f1d0fa5b5db7fe08de640610f3fdbdbed8fb2f/lib/core/evaluate.py#L55
Did you find out what it's for?
I have same confusion!
I found that norm
should be torso size or something else (like the head size as referred to PCKh).
But their accuracy function in evaluate.py
was made for just checking if the training works well (https://github.com/princeton-vl/pose-hg-train#training-accuracy-metric).
The accuracy function calculates within heatmap space (see the difference between get_max_preds and get_final_preds functions in inference.py
).
I think this is against the rule, which is the x, y coordinates (max activation in heatmaps) should be compared within original space, but most of HPE models use this function to evaluate the PCK metric (not sure).
So, that denominator factor makes the norm
as heatmap size / 10, and maybe this is regarded as torso size in heatmap space.
Looking at the order of the indexes in the output of get_max_preds
https://github.com/microsoft/human-pose-estimation.pytorch/blob/18f1d0fa5b5db7fe08de640610f3fdbdbed8fb2f/lib/core/inference.py#L39-L40
This line
https://github.com/microsoft/human-pose-estimation.pytorch/blob/18f1d0fa5b5db7fe08de640610f3fdbdbed8fb2f/lib/core/evaluate.py#L55
shouldn't be as following (i.e. with inverted h and w)?
norm = np.ones((pred.shape[0], 2)) * np.array([w, h]) / 10
@stefanopini
Yes, I think you're right. But it would not raise any error as the heatmap's resolution is 64x64 in most cases.
@aFewThings thank you for looking at it! That's true, it doesn't result in any error as long as the heatmaps are squared.
However, the same code is used also in HRNet which is trained with non-squared input and thus non-squared heatmaps. I'll open an issue there, thanks!