doc/advanced/demo_advanced.md
This document is a more detailed continuation of doc/01_demo.md, and it assumes the user is quite familiar with the OpenPose demo and the contents of doc/01_demo.md.
In general, there are 3 ways to reduce the latency (with some drawbacks each one):
--output_resolution: It will slightly reduce the latency and increase the FPS. But the quality of the displayed image will deteriorate.--net_resolution and/or --face_net_resolution and/or --hand_net_resolution: It will increase the FPS and reduce the latency. But the accuracy will drop, specially for small people in the image. Note: For maximum accuracy, follow doc/01_demo.md#maximum-accuracy-configuration.--disable_multi_thread: The latency should be reduced. But the speed will drop to 1-GPU speed (as it will only use 1 GPU). Note that it's practical only for body, if hands and face are also extracted, it's usually not worth it.# Fast method for speed
./build/examples/openpose/openpose.bin --hand
# Best results found with 6 scales
./build/examples/openpose/openpose.bin --hand --hand_scale_number 6 --hand_scale_range 0.4
# Adding tracking to Webcam (if FPS per GPU > 10 FPS) and Video
./build/examples/openpose/openpose.bin --video examples/media/video.avi --hand --hand_detector 3
# Multi-scale + tracking is also possible
./build/examples/openpose/openpose.bin --video examples/media/video.avi --hand --hand_scale_number 6 --hand_scale_range 0.4 --hand_detector 3
# CPU rendering (faster)
./build/examples/openpose/openpose.bin --render_pose 0 --face --face_render 1 --hand --hand_render 1
# GPU rendering
./build/examples/openpose/openpose.bin --render_pose 0 --face --face_render 2 --hand --hand_render 2
# Basic information
./build/examples/openpose/openpose.bin --logging_level 3
# Showing all messages
./build/examples/openpose/openpose.bin --logging_level 0
The following command will save all the body part heat maps, background heat map and Part Affinity Fields (PAFs) in the folder output_heatmaps_folder. It will save them on PNG format. Instead of individually saving each of the 67 heatmaps (18 body parts + background + 2 x 19 PAFs) individually, the library concatenate them vertically into a huge (width x #heatmaps) x (height) matrix. The PAFs channels are multiplied by 2 because there is one heatmpa for the x-coordinates and one for the y-coordinates. The order is body parts + bkg + PAFs. It will follow the sequence on POSE_BODY_PART_MAPPING in include/openpose/pose/poseParameters.hpp.
./build/examples/openpose/openpose.bin --video examples/media/video.avi --heatmaps_add_parts --heatmaps_add_bkg --heatmaps_add_PAFs --write_heatmaps output_heatmaps_folder/
The BODY_25 model (--model_pose BODY_25) includes both body and foot keypoints and it is based in OpenPose: Realtime Multi-Person 2D Pose Estimation using Part Affinity Fields. COCO and MPI models are slower, less accurate, and do not contain foot keypoints. They are based in our older paper Realtime Multi-Person 2D Pose Estimation using Part Affinity Fields. We highly recommend only using the BODY_25 model.
There is an exception, for CPU version, the COCO and MPI models seems to be faster. Accuracy is still better for the BODY_25 model.
We recommend following the next section (All Flags), which shows all the flags in this document and sorts them by category.
However, you could add the flag --help at any point to see all the available OpenPose flags. Check only the flags for examples/openpose/openpose.cpp itself (i.e., the ones in the section Flags from examples/openpose/openpose.cpp:).
# Ubuntu and Mac
./build/examples/openpose/openpose.bin --help
:: Windows - Portable Demo
bin\OpenPoseDemo.exe --help
Now that you are more familiar with OpenPose, this is a list with all the available flags. Each one is divided into flag name, default value, and description.
--camera or --flir_camera). -1x-1 will use the default 1280x720 for --camera, or the maximum flir camera resolution available for --flir_camera");examples/media/video.avi for our default example video.");examples/media/ for our default example folder with 20 images. Read all standard formats (jpg, png, bmp, etc.).");n to the n-th lowest serial number camera.");--frame_step 5 would read and process frames 0, 5, 10, etc..");camera_parameter_path");--model_folder + --prototxt_path represents the whole path to the prototxt file. If empty, it will use the default OpenPose ProtoTxt file.");--model_folder + --caffemodel_path represents the whole path to the caffemodel file. If empty, it will use the default OpenPose CaffeModel file.");write_json & write_keypoint flags. Select 0 to scale it to the original source resolution; 1to scale it to the net output size (set with net_resolution); 2 to scale it to the final output size (set with resolution); 3 to scale it in the range [0,1], where (0,0) would be the top-left corner of the image, and (1,1) the bottom-right one; and 4 for range [-1,1], where (-1,-1) would be the top-left corner of the image, and (1,1) the bottom-right one. Non related with scale_number and scale_gap.");BODY_25 (fastest for CUDA version, most accurate, and includes foot keypoints), COCO (18 keypoints), MPI (15 keypoints, least accurate model but fastest on CPU), MPI_4_layers (15 keypoints, even faster but less accurate).");-1 in any of the dimensions, OP will choose the optimal aspect ratio depending on the user's input value. E.g., the default -1x368 is equivalent to 656x368 in 16:9 resolutions, e.g., full HD (1980x1080) and HD (1280x720) resolutions.");-1 in net_resolution will behave as explained in its description. Otherwise, and to avoid out of memory errors, the -1 in net_resolution will clip to this value times the default 16/9 aspect ratio value (which is 656 width for a 368 height). E.g., net_resolution_dynamic 10 net_resolution -1x368 will clip to 6560x368 (10 x 656). Recommended 1 for small GPUs (to avoid out of memory errors but maximize speed) and 0 for big GPUs (for maximum accuracy and speed).");net_resolution by your desired initial scale.");net_resolution and the output net results. A value less or equal than 0 (default) will use the network default value (recommended).");add_heatmaps_X flag is enabled, it will place then in sequential memory order: body parts + bkg + PAFs. It will follow the order on POSE_BODY_PART_MAPPING in src/openpose/pose/poseParameters.cpp. Program speed will considerably decrease. Not required for OpenPose, enable it only if you intend to explicitly use this information later.");add_heatmaps_parts, but adding the heatmap corresponding to background.");add_heatmaps_parts, but adding the PAFs.");write_json in order to save this information. If true, it will fill the op::Datum::poseCandidates array with the body part candidates. Candidates refer to all the detected body parts, before being assembled into people. Note that the number of candidates is equal or higher than the number of final body parts (i.e., after being assembled into people). The empty body parts are filled with 0s. Program speed will slightly decrease. Not required for OpenPose, enable it only if you intend to explicitly use this information.");model_folder. Note that this will considerable slow down the performance and increase the required GPU memory. In addition, the greater number of people on the image, the slower OpenPose will be.");net_resolution but applied to the face keypoint detector. 320x320 usually works fine while giving a substantial speed up when multiple faces on the image.");model_folder. Analogously to --face, it will also slow down the performance, increase the required GPU memory and its speed depends on the number of people.");--face_detector.");net_resolution but applied to the hand keypoint detector.");scale_number but applied to the hand keypoint detector. Our best results were found with hand_scale_number = 6 and hand_scale_range = 0.4.");scale_gap but applied to the hand keypoint detector. Total range between smallest and biggest scale. The scales will be centered in ratio 1. E.g., if scaleRange = 0.4 and scalesNumber = 2, then there will be 2 scales, 0.8 and 1.2.");--image_dir or --video. OpenPose will read as many images per iteration, allowing tasks such as stereo camera processing (--3d). Note that --camera_parameter_path must be set. OpenPose must find as many xml files in the parameter folder as this number indicates.");part_to_show, alpha_pose, and alpha_pose.");alpha_X flags). If -1, it will pick CPU if CPU_ONLY is enabled, or GPU if CUDA is enabled. If rendering is enabled, it will render both outputData and cvOutputData with the original image and desired body part to be shown (i.e., keypoints, heat maps or PAFs).");render_threshold, but applied to the face keypoints.");render_pose but applied to the face. Extra option: -1 to use the same configuration that render_pose is using.");alpha_pose but applied to face.");alpha_heatmap but applied to face.");render_threshold, but applied to the hand keypoints.");render_pose but applied to the hand. Extra option: -1 to use the same configuration that render_pose is using.");alpha_pose but applied to hand.");alpha_heatmap but applied to hand.");--3d enabled); and 1 for both 2-D and 3-D display.");verbose frames. If number in the range (0,1), it will print the progress every verbose times the total of frames.");write_images_format image format.");write_images, e.g., png, jpg or bmp. Check the OpenCV function cv::imwrite for all compatible extensions.");.avi. It internally uses cv::VideoWriter. Flag write_video_fps controls FPS. Alternatively, the video extension can be .mp4, resulting in a file with a much smaller size and allowing --write_video_with_audio. However, that would require: 1) Ubuntu or Mac system, 2) FFmpeg library installed (sudo apt-get install ffmpeg), 3) the creation temporarily of a folder with the same file path than the final video (without the extension) to storage the intermediate frames that will later be used to generate the final MP4 video.");.mp4 format (see write_video for details).");--write_video, but applied to the 3D output.");--write_video, but applied to Adam model.");--part_candidates enabled).");--write_coco_json_variants), they are saved with different file name suffix.");add_heatmaps_X flag must be enabled.");write_heatmaps, analogous to write_images_format. For lossless compression, recommended png for integer heatmaps_scale and float for floating values. See doc/02_output.md for more details.");write_json) Directory to write the people pose keypoint data. Set format with write_keypoint_format.");write_json) File extension and format for write_keypoint: json, xml, yaml & yml. Json not available for OpenCV < 3.0, use write_json instead.");~/Desktop/mocapResult.bvh.");192.168.0.1.");