Human Pose Estimation Python* Demo

This demo showcases the work of multi-person 2D pose estimation algorithms. The task is to predict a pose: body skeleton, which consists of a predefined set of keypoints and connections between them, for every person in an input image/video.

How It Works

On the start-up, the application reads command-line parameters and loads a network to the Inference Engine. Upon getting a frame from the OpenCV VideoCapture, it performs inference and displays the results.

NOTE: By default, Open Model Zoo demos expect input with BGR channels order. If you trained your model to work

with RGB order, you need to manually rearrange the default channels order in the demo application or reconvert your model using the Model Optimizer tool with --reverse_input_channels argument specified. For more information about the argument, refer to When to Reverse Input Channels section of Converting a Model Using General Conversion Parameters.


Running the application with the -h option yields the following usage message:

usage: [-h] -m MODEL -at {ae,openpose} -i INPUT
[--loop] [-o OUTPUT]
[-nstreams NUM_STREAMS]
[-nthreads NUM_THREADS] [-no_show]
-h, --help Show this help message and exit.
-m MODEL, --model MODEL
Required. Path to an .xml file with a trained model.
-at {ae,openpose}, --architecture_type {ae,openpose}
Required. Specify model' architecture type.
-i INPUT, --input INPUT
Required. An input to process. The input must be a
single image, a folder of images, video file or camera
--loop Optional. Enable reading the input in a loop.
-o OUTPUT, --output OUTPUT
Optional. Name of output to save.
-limit OUTPUT_LIMIT, --output_limit OUTPUT_LIMIT
Optional. Number of frames to store in output. If 0 is
set, all frames are stored.
-d DEVICE, --device DEVICE
Optional. Specify the target device to infer on; CPU,
GPU, FPGA, HDDL or MYRIAD is acceptable. The sample
will look for a suitable plugin for device specified.
Default value is CPU.
Common model options:
Optional. Probability threshold for poses filtering.
--tsize TSIZE Optional. Target input size. This demo implements
image pre-processing pipeline that is common to human
pose estimation approaches. Image is first resized to
some target size and then the network is reshaped to
fit the input image shape. By default target image
size is determined based on the input shape from IR.
Alternatively it can be manually set via this
parameter. Note that for OpenPose-like nets image is
resized to a predefined height, which is the target
size in this case. For Associative Embedding-like nets
target size is the length of a short first image side.
Inference options:
-nireq NUM_INFER_REQUESTS, --num_infer_requests NUM_INFER_REQUESTS
Optional. Number of infer requests
-nstreams NUM_STREAMS, --num_streams NUM_STREAMS
Optional. Number of streams to use for inference on
the CPU or/and GPU in throughput mode (for HETERO and
MULTI device cases use format
<device1>:<nstreams1>,<device2>:<nstreams2> or just
-nthreads NUM_THREADS, --num_threads NUM_THREADS
Optional. Number of threads to use for inference on
CPU (including HETERO cases).
Input/output options:
-no_show, --no_show Optional. Don't show output.
Optional. List of monitors to show initially.
Debug options:
-r, --raw_output_message
Optional. Output inference results raw values showing.

Running the application with the empty list of options yields the short usage message and an error message. You can use the following command to do inference on CPU with a pre-trained human pose estimation model:

python3 -i 0 -m human-pose-estimation-0002.xml -at ae -d CPU

To run the demo, you can use public or pre-trained models. You can download the pre-trained models with the OpenVINO Model Downloader.

NOTE: Before running the demo with a trained model, make sure the model is converted to the Inference Engine

format (*.xml + *.bin) using the Model Optimizer tool.

Demo Output

The demo uses OpenCV to display the resulting frame with estimated poses. The demo reports

  • FPS: average rate of video frame processing (frames per second)
  • Latency: average time required to process one frame (from reading the frame to displaying the results) You can use both of these metrics to measure application-level performance.

See Also