OpenPose represents the **first real-time multi-person system to jointly detect human body, hand, and facial keypoints (in total 130 keypoints) on single images**.
[OpenPose](https://github.com/CMU-Perceptual-Computing-Lab/openpose) represents the **first real-time multi-person system to jointly detect human body, hand, and facial keypoints (in total 130 keypoints) on single images**.
@@ -13,8 +13,8 @@ OpenPose C++ API - How to Develop OpenPose
1. Class parameters should start with `m`, class pointers with `p`, shared_ptrs with `sp`, unique_ptrs with `up`, static parameters with `s`.
2. Function and class parameters coding style is the same other than the previous point.
3. Any parameters should not contain special characters, simply letters and numbers (preferred only letters) separated with upper case. E.g., `mThisIsAParameter`, `thisIsAParameter`.
4. In addition, the names should be self-explanatory and not abbreviated. Good examples: `counter`, `thisIs. Bad examples: `ctr`, `var`.
3. Lenght:
4. In addition, the names should be self-explanatory and not abbreviated. Good examples: `counter`, `thisIs`. Bad examples: `ctr`, `var`.
3. Length:
1. Lines should contain up to 120 characters.
4. Comments:
1. Only `//` comments are allowed in the code, `/* */` should not be used.
...
...
@@ -34,15 +34,18 @@ else
```
6. Includes:
1. They should be sorted in this order:
1. There cannot be any include to a 3rd party in the headers (other than OpenCV core: `opencv2/core/core.hpp`).
1. PImpl idiom can be checked (e.g., in `include/openpose/pose/poseExtractorCaffe.hpp`) for an idea of how to avoid it.
2. Otherwise the defining class examples in `include/openpose/core/macros.hpp` (point 1 is highly preferred).
2. They should be sorted in this order:
1. Std libraries.
2. OS libraries.
3. 3rd party libraries (e.g. Caffe, OpenCV).
4. OpenPose libraries.
5. If it is a cpp file, the last one should be its own hpp.
2. Inside each of the previous groups, it should be sorted alphabetically.
3. Inside each of the previous groups, it should be sorted alphabetically.
7. Functions arguments:
1. It should first include the variables to be edited, and secondtly the const variables.
1. It should first include the variables to be edited, and secondly the const variables.
2. Any variable that is not gonna be modified must be added with `const`.
8. Pointers:
1. Pointers must be avoided if possible.
...
...
@@ -64,7 +67,7 @@ This is the faster method to debug a segmentation fault problem. Usual scenario:
1. Comment `#ifndef NDEBUG` and its else and endif.
2. Call OpenPose with `--logging_level 0 --disable_multi_thread`.
3. At this point you have an idea of in which file class the segmentation fault is coming from. Now you can further isolate the error by iteratively adding the following line all over the code until you find the exact position of the segmentation fault: `log("", Priority::Low, __LINE__, __FUNCTION__, __FILE__);`
4. After you have found the segmentation fault, remember to remove all the extra `log()` calls that you temporaryly added.
4. After you have found the segmentation fault, remember to remove all the extra `log()` calls that you temporarily added.
...
...
@@ -86,7 +89,7 @@ This is the faster method to debug a segmentation fault problem. Usual scenario:
3. Get JSONs in OpenPose: examples/tests/pose_accuracy_coco_val.sh
4. Get accuracy (Matlab): validation/f_getValidations.m
### Checking Ground-Truth Labes
### Checking Ground-Truth Labels
From the [COCO dataset](http://cocodataset.org/#download):
1. Download 2014 or 2017 Train/Val annotations.
2. Download the [COCO API](https://github.com/cocodataset/cocoapi).
