[Feat] Add COCOPoseMetric

[LareinaM]

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.

Motivation

Add COCOPoseMetric for pose estimation task.

PR in mmpose: open-mmlab/mmpose#1777, about the results verification.

Modification

1. Add COCOPoseMetric under mmeval/metrics/coco_pose.py.
2. Add some test data: tests/test_metrics/data/coco_pose_sample.json, tests/test_metrics/data/crowdpose_sample.json, tests/test_metrics/data/ap10k_sample.json and unit tests.
3. Add nms function under mmeval/metrics/utils/nms.py.

BC-breaking (Optional)

Does the modification introduce changes that break the backward-compatibility of the downstream repos?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.

Use cases (Optional)

If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.

Checklist

1. Pre-commit or other linting tools are used to fix the potential lint issues.
2. The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
3. If the modification has potential influence on downstream projects, this PR should be tested with downstream projects, like MMDet or MMCls.
4. The documentation has been modified accordingly, like docstring or example tutorials.

Comments

1. Change of examples in mmeval/metrics/coco_pose.py: add case and simplify input
2. Fix all formats and typos
3. add function aims at keeping consistent with that of COCODetection, and after discussion, no modification is made
4. Indents in the files are implied by yapf hook

[C1rN09]

What about making groundtruths defaults to None so that it's easier for users to use it with ann_file != None? Creating an 'empty' groundtruths is ambiguous and inconvenient, since we require it has the same length as predictions

[C1rN09]

I think there should be some new design or discussions.

[LareinaM]

Our thoughts were to keep consistent with that of COCODetection, maybe this needs further discussions with the team.

[C1rN09]

predictions is instance-level while groundtruths is image-level. Usually they are of different length, i.e. N predictions in 1 image. How to make them of the same length? I think the design of input type is not reasonable.

[LareinaM]

I think the developer assumed both to be of instance-level. Also can be inferred from the unit test.

[C1rN09]

What's the meaning of id in predictions? Is there only 1 instance in each image, or there might be multiple instances in an image? How to match your detections with groundtruths without knowing the groundtruths, i.e. same number of detections as groundtruths?

I'm not familiar with the format, but seems like raw_ann_info in groundtruth covers all instances' labels in a single image. Please clarify if I misunderstood.

[LareinaM]

There might be multiple instances in an image. For example, in coco_pose_sample.json, there are three entries with "image_id": 40083, because in the image, there are three people. The three instances have different and unique ids.

In compute_metric, groundtruths (a list of groundtruth instances) are represented by a COCO format json file, while predicted instances of the same image are grouped together and dumped into another json file. The evaluation results are calculated by COCOeval by reading the above two files.

Each ann (raw_ann_info) represents an instance, with information of the groundtruth keypoints and bboxes, etc.