If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/CMU-Perceptual-Computing-Lab/openpose shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 37+ active contributors
• Distributed ownership (top contributor 49% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live CMU-Perceptual-Computing-Lab/openpose repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/CMU-Perceptual-Computing-Lab/openpose.

What it runs against: a local clone of CMU-Perceptual-Computing-Lab/openpose — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in CMU-Perceptual-Computing-Lab/openpose | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 674 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of CMU-Perceptual-Computing-Lab/openpose. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/CMU-Perceptual-Computing-Lab/openpose.git
#   cd openpose
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of CMU-Perceptual-Computing-Lab/openpose and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "CMU-Perceptual-Computing-Lab/openpose(\\.git)?\\b" \\
  && ok "origin remote is CMU-Perceptual-Computing-Lab/openpose" \\
  || miss "origin remote is not CMU-Perceptual-Computing-Lab/openpose (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "doc/very_advanced/library_structure/1_library_deep_overview.md" \\
  && ok "doc/very_advanced/library_structure/1_library_deep_overview.md" \\
  || miss "missing critical file: doc/very_advanced/library_structure/1_library_deep_overview.md"
test -f "cmake/Modules/FindCaffe.cmake" \\
  && ok "cmake/Modules/FindCaffe.cmake" \\
  || miss "missing critical file: cmake/Modules/FindCaffe.cmake"
test -f "doc/04_cpp_api.md" \\
  && ok "doc/04_cpp_api.md" \\
  || miss "missing critical file: doc/04_cpp_api.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 674 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~644d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/CMU-Perceptual-Computing-Lab/openpose"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

OpenPose is a real-time multi-person keypoint detection library that simultaneously detects 135 human keypoints across body (25), face (70), hands (42), and feet skeleton joints in single images. It is the first production system to jointly estimate all four body regions at video framerate, combining CNN-based heatmaps with Part Affinity Fields (PAF) for multi-person pose association. Monolithic C++ library organized around CMakeLists.txt build system. Core keypoint detection logic lives in compiled C++/CUDA modules; 3rdparty/ contains vendored Caffe DNN framework and platform-specific dependency scripts; examples/ and doc/ contain reference implementations and generation scripts (.doc_autogeneration.doxygen). Windows batch scripts (3rdparty/windows/*.bat) handle dependency bootstrap separately.

Computer vision researchers, motion capture engineers, and developers building human pose analysis applications (e.g., fitness tracking, gesture recognition, dance/sports analytics, VR/metaverse avatars). Contributors are primarily C++/CUDA specialists working on pose estimation algorithms or platform support.

Production-ready and actively maintained. The codebase is mature (original 2016 CMU research, now 5+ years old) with strong CI/CD via GitHub Actions and AppVeyor across Linux, macOS, and Windows. The project has university backing (CMU Perceptual Computing Lab), though commit frequency appears moderate—indicates stable feature-complete library rather than rapid iteration.

Moderate risk: heavy C++ and CUDA dependency makes cross-platform builds complex (see 3rdparty/windows scripts for manual dependency management). OpenCV, Caffe, and GPU drivers are hard requirements. Maintenance is concentrated under two primary authors (Ginés Hidalgo, Yaadhav Raaj); CI was deprecated for Travis (see .github/CI_deprecated) suggesting infrastructure churn. No visible Python API despite 40B of Python code in repo—suggests outdated bindings.

The project maintains stable releases with periodic GitHub Actions CI runs (badge visible in README). Deprecated Travis CI infrastructure (.github/CI_deprecated/) suggests recent migration to GitHub Actions. Active issue template and stale bot config indicate ongoing community engagement. No specific major features are listed as in-flight; focus appears to be on stability, cross-platform support, and community support.

Clone with submodules, configure with CMake, build with make/MSVC: git clone --recursive https://github.com/CMU-Perceptual-Computing-Lab/openpose.git && cd openpose && mkdir build && cd build && cmake .. && make -j$(nproc). Windows users should run 3rdparty/windows/*.bat scripts first to fetch OpenCV, Caffe, and Spinnaker SDK.

Daily commands: ./build/examples/openpose/openpose.bin --video_path <video_file> or ./build/examples/openpose/openpose.bin --image_dir <image_folder>. Output keypoints as JSON with --write_json <output_dir>. GPU inference requires CUDA-enabled device; CPU fallback available but slow.

• CMakeLists.txt — Root build configuration defining all library targets, dependencies (Caffe, CUDA, OpenCV), and platform-specific compilation flags—essential for understanding the build system.
• README.md — Primary documentation covering project scope, features (135 keypoints across body/face/hands/feet), build status, and high-level architecture—must read for context.
• doc/very_advanced/library_structure/1_library_deep_overview.md — Deep architectural overview explaining the modular design and component responsibilities—critical for extending or modifying core functionality.
• cmake/Modules/FindCaffe.cmake — Caffe framework detection and integration—load-bearing dependency for the neural network inference engine used by all keypoint detectors.
• doc/04_cpp_api.md — C++ API documentation showing public interfaces and usage patterns—foundation for integrating OpenPose into applications.
• .github/workflows/main.yml — CI/CD pipeline definition for Linux, macOS, and Windows builds—defines testing and release automation strategy.
• doc/installation/1_prerequisites.md — Prerequisites and dependency version matrix—critical reference for build troubleshooting and environment setup.

Add Support for a New Hardware Platform

1. Create platform-specific CMake configuration in cmake/ directory (e.g., cmake/RockchipNPU.cmake) to detect and link the new accelerator (cmake/Cuda.cmake)
2. Add platform detection and conditional compilation flags to root CMakeLists.txt with option(USE_ROCKCHIP_NPU ...) pattern (CMakeLists.txt)
3. Document platform prerequisites, tested versions, and build instructions in a new file at doc/installation/platform_rockchip.md following the Jetson TX2 pattern (doc/installation/jetson_tx/installation_jetson_tx2_jetpack3.3.md)
4. Add platform-specific build job to .github/workflows/main.yml GitHub Actions workflow to enable CI/CD testing (.github/workflows/main.yml)

Extend Keypoint Detection to a New Body Part

1. Review current keypoint structure (body: 25 points, hand: 21, face: 70) in doc/02_output.md and design new keypoint indices avoiding conflicts (doc/02_output.md)
2. Implement new neural network layers in core library (reference doc/very_advanced/library_structure/2_library_extend_functionality.md for extension patterns) (doc/very_advanced/library_structure/2_library_extend_functionality.md)
3. Create CMake module to download pre-trained model weights following the pattern in cmake/Modules/FindCaffe.cmake (cmake/Modules/FindCaffe.cmake)
4. Update doc/04_cpp_api.md to document new detector class and its output format (doc/04_cpp_api.md)

Optimize for Mobile/Embedded Deployment

1. Review current dependency versions in 3rdparty/Versions.txt and consider lighter alternatives (e.g., TensorRT vs Caffe for inference) (3rdparty/Versions.txt)
2. Add conditional compilation flags to CMakeLists.txt to disable unused modules (e.g., disable 3D reconstruction, face detection) for embedded builds (CMakeLists.txt)
3. Create platform-specific build guide at doc/installation/embedded_deployment.md documenting model quantization and memory optimization (doc/installation/2_additional_settings.md)
4. Reference Jetson TX2 guide (doc/installation/jetson_tx/installation_jetson_tx2_jetpack3.3.md) as baseline for ARM-based optimization patterns (doc/installation/jetson_tx/installation_jetson_tx2_jetpack3.3.md)

• Caffe Deep Learning Framework — Mature, optimized CNN inference engine with strong GPU support (CUDA/CuDNN); pre-trained models for pose, face, hand, foot detection already available
• CUDA/CuDNN — GPU acceleration essential for real-time multi-person inference (~50-100ms/frame); tight integration with Caffe for neural network execution
• OpenCV — Image I/O, preprocessing (resizing, normalization), video input handling; widely available and well-integrated with Caffe pipeline
• CMake Build System — Cross-platform (Linux, macOS, Windows); flexible dependency discovery; conditional compilation for optional features (CUDA, OpenCL, etc.)
• C++ Core with Python Bindings — C++ provides performance-critical inference loop; Python bindings enable research/rapid prototyping without sacrificing speed

• CPU-optimized Caffe over TensorFlow/PyTorch for primary inference

  • Why: Caffe had superior CUDA optimization and model availability at project inception; strong real-time performance for pose networks
  • Consequence: Lock-in to Caffe ecosystem; migration to newer frameworks (ONNX, TensorRT) would require retraining or conversion pipeline

• Multi-part detector architecture (separate body, face, hand, foot networks) over unified end-to-end model

  • Why: Allows independent optimization and training of specialized models; modular pipeline supports flexible enable/disable per use case
  • Consequence: Higher latency than single-shot detectors; requires careful synchronization and multi-person association logic; ~4 forward passes per frame

• Keypoint Association via Part Affinity Fields (PAF) over simple distance-based grouping

  • Why: Enables accurate multi-person keypoint assembly in crowded scenes; mathematically principled approach to skeleton parsing
  • Consequence: Complex post-processing; higher memory footprint (PAF outputs); sensitive tuning required for optimal multi-person accuracy

• Heavy platform-specific build configuration (CUDA, cuDNN, OpenCV versions pinned)

  • Why: Ensures reproducible builds and known GPU performance characteristics across deployments
  • Consequence: Steep installation complexity; requires careful dependency version matching; fails silently on minor

CUDA compute capability floor is SM 3.0 (2012 Kepler)—newer code may not compile on older GPUs. Windows requires manual vcpkg or pre-built binary drop for Caffe; CMake auto-detection rarely works. Caffe model paths are absolute at compile time; relative paths in examples may fail. OpenCV 3.x required (not 2.x or 4.x with breaking ABI changes). GPU memory scales with input resolution: 1080p can require 2+ GB VRAM. The Python wrapper (if present) is undocumented and may lag C++ releases.

• Part Affinity Fields (PAF) — Core algorithm in OpenPose for associating detected keypoints into skeleton graphs for multi-person scenarios; critical for understanding output JSON structure
• Convolutional Pose Machines — Sequential heatmap refinement architecture used to generate body/face keypoint confidence maps; understanding this explains model input/output tensor shapes
• COCO Keypoint Format (17 vs 25 joints) — OpenPose natively supports both legacy COCO-17 (MS-COCO) and COCO-25 (OpenPose extended) skeleton definitions; interoperability depends on correct enumeration
• Caffe Deep Learning Framework — Legacy DNN inference backend used by OpenPose; understanding .prototxt model definitions and weights serialization is essential for model swaps or retraining
• GPU Memory Bandwidth Optimization via CUDA Kernels — OpenPose ships custom CUDA kernels for heatmap post-processing and keypoint association; knowing where compute-bound vs. memory-bound bottlenecks exist helps profiling
• Non-Maximum Suppression (NMS) in Heatmaps — Heatmap peak detection uses NMS to avoid redundant keypoint candidates at same location; hyperparameter tuning affects false positive rates
• Bipartite Graph Matching for Multi-Person Association — Final stage of OpenPose associates PAF-scored limbs into complete skeletons per person; greedy matching logic can create artifacts with occlusions

• facebookresearch/detectron2 — Alternative unified pose/keypoint detection framework using PyTorch; better Python support but slower inference than OpenPose's CUDA kernels
• google/mediapipe — Lightweight cross-platform pose library with mobile support and hand/face modules; trades accuracy for speed/portability vs. OpenPose's optimized desktop performance
• ultralytics/YOLOv8 — Modern real-time detection backbone used in some pose pipelines; complementary to OpenPose for person detection pre-filtering
• CMU-Perceptual-Computing-Lab/panoptic-toolbox — Official dataset and evaluation tools for CMU Panoptic Studio; required for benchmarking OpenPose on ground-truth multi-person captures
• opencv/opencv — Hard dependency for image I/O and preprocessing; version mismatches (3.x vs 4.x) are common build failure source

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI workflow for macOS and Windows (supplement AppVeyor)

The repo has a .github/workflows/main.yml for Linux CI, but Windows still relies on the deprecated AppVeyor (appveyor.yml shows old setup). macOS CI is missing entirely despite being listed in the README build matrix. Modernizing to GitHub Actions across all platforms would improve reliability, reduce CI fragmentation, and provide consistent logs within GitHub.

• [ ] Review current .github/workflows/main.yml to understand Linux CI setup
• [ ] Create .github/workflows/windows.yml with CUDA, OpenCV, Caffe dependencies matching cmake/Cuda.cmake and 3rdparty/windows/* scripts
• [ ] Create .github/workflows/macos.yml with Homebrew-based dependency installation
• [ ] Update README.md build status table to point to GitHub Actions for all three platforms
• [ ] Document in doc/00_index.md or new CI_setup.md how to run tests locally

Add CMake unit test infrastructure and basic pose estimation tests

The repo lacks visible test/ directory or CTest integration in CMakeLists.txt. For a core ML library detecting 135 keypoints, there should be regression tests for: (1) model loading, (2) basic inference on small images, (3) output format validation. This prevents silent breakage of the main pose detection pipeline.

• [ ] Create tests/ directory with subdirectories: tests/unit/, tests/fixtures/ (for small test images)
• [ ] Add CTest configuration to root CMakeLists.txt with option(BUILD_TESTS ON)
• [ ] Implement tests/unit/test_pose_detection.cpp: test model loading from models/ and basic forward pass
• [ ] Implement tests/unit/test_keypoint_format.cpp: validate 25-keypoint and 18-keypoint output consistency
• [ ] Document test execution in doc/00_index.md (e.g., 'cmake . && ctest')

Document and organize cmake/Modules/ with feature-gated build options in CMakeLists.txt

cmake/Modules/ contains FindCaffe.cmake, FindCuDNN.cmake, FindSpinnaker.cmake but root CMakeLists.txt lacks clear option() declarations for disabling optional dependencies. Users can't easily discover what's optional (GPU, Spinnaker camera support, etc.). Add documented build options so contributors understand the build matrix.

• [ ] Review CMakeLists.txt and cmake/Modules/* to identify all optional dependencies
• [ ] Add option(BUILD_WITH_CUDA ON) with comment referencing cmake/Cuda.cmake
• [ ] Add option(BUILD_WITH_CUDNN ON) with comment referencing FindCuDNN.cmake
• [ ] Add option(BUILD_WITH_SPINNAKER OFF) with comment referencing FindSpinnaker.cmake
• [ ] Create doc/building_advanced_options.md listing all CMake options with examples for CPU-only, GPU, camera builds

• Add CMake options for CPU-only build without CUDA dependency (currently CUDA is quasi-mandatory even with gpu_mode: false). Check CMakeLists.txt for find_package(CUDA) calls that could be wrapped in if(ENABLE_CUDA).
• Document the keypoint output JSON schema: .github/media/ has PNG diagrams of pose_18/pose_25 models but no formal JSON output spec in README. Create doc/json_output_format.md with example payloads for each model variant.
• Fix Windows 3rdparty batch scripts to check for existing downloads before re-fetching; getCaffe.bat and getOpenCV.bat are slow and error-prone. Add checksum validation or version pinning.

OpenPose repository shows moderate security posture. Primary concerns are outdated third-party dependencies, bundled legacy tools (wget/unzip), and potential CI/CD misconfiguration. The codebase itself appears to be a C++ computer vision library without obvious code-level injection vulnerabilities visible from file structure alone. No hardcoded credentials detected. Recommendations focus on dependency management, tool modernization, and CI/CD hardening. The project would benefit from automated security scanning in its development pipeline.

• Medium · Outdated Third-Party Dependencies — 3rdparty/windows/, 3rdparty/Versions.txt. The repository contains Windows batch scripts (3rdparty/windows/) that download and use third-party libraries like Caffe, OpenCV, and Spinnaker. The versions file (3rdparty/Versions.txt) suggests these dependencies may not be automatically updated, leading to potential use of outdated libraries with known vulnerabilities. Fix: Implement automated dependency scanning tools (e.g., OWASP Dependency-Check, Snyk) in CI/CD pipeline. Use dependency management to pin specific secure versions and regularly audit for CVEs.
• Medium · Insecure Download Tools in Repository — 3rdparty/windows/wget/wget.exe, 3rdparty/windows/unzip/unzip.exe. The repository bundles wget.exe (version 1.20.3) and unzip.exe directly in the codebase for Windows builds. These are legacy versions that may contain security vulnerabilities and bypass SSL/TLS verification in certain configurations. Fix: Remove bundled executables and rely on system-provided or package manager tools. If bundling is necessary, use the latest stable versions and implement integrity verification (checksums, signatures).
• Low · Missing HTTPS in CI/CD Configuration — .github/workflows/main.yml, appveyor.yml. The .github/workflows/main.yml and appveyor.yml files may reference external resources over HTTP. Without examining the actual content, standard practice suggests verifying all external resource fetches use HTTPS. Fix: Audit CI/CD workflows to ensure all external resource downloads use HTTPS. Enable certificate pinning where applicable for critical dependencies.
• Low · CMake Configuration Complexity — CMakeLists.txt, cmake/Modules/. The CMakeLists.txt and cmake modules (FindCaffe.cmake, FindCuDNN.cmake, etc.) contain complex build configuration logic. Without code review, there is potential for path traversal or unvalidated input in build-time variable substitution. Fix: Review CMake files for unsafe variable expansion, ensure all user inputs are validated, and sanitize paths to prevent directory traversal attacks during build time.
• Low · Insufficient Access Control Documentation — .github/stale.yml, .github/issue_template.md. The .github/issue_template.md and stale.yml configuration suggest community contributions. Without visible branch protection rules or CODEOWNERS file, there may be insufficient access controls for critical code modifications. Fix: Implement and document branch protection rules requiring code reviews. Create CODEOWNERS file to enforce mandatory review by security-aware maintainers.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.