CenterPose: Optimized for AMD ROCm
CenterPose is a single-stage, keypoint-based 6-DoF object pose estimator that recovers 3D bounding boxes and full rotation/translation from a single RGB image. This repository packages evaluation/inference for 6-DoF object pose estimation using PyTorch, exported and validated for AMD ROCm so it runs efficiently on AMD GPUs and CPUs.
This repository contains configurations and scripts optimized for AMD® ROCm™ platforms. You can use the CenterPose AMD scripts to reproduce results or export with custom configurations. More details on model performance can be found here.
Task Overview
Task: 6-DoF object pose estimation (single RGB image)
Dataset: Objectron sample images (bundled — cup, chair categories; 9 images, 12 detections)
Output metrics: 3D IoU, 2D MPE (px), Azimuth Error (deg), Elevation Error (deg), ADD (normalized), AP@5°/10°/15°/30° Azimuth, AP@3D IoU 25/50/75
PyTorch note: CPU and GPU both run FP32 via the same PyTorch code path — no ONNX Runtime is involved. The DCNv2 op is replaced by
torchvision.ops.deform_conv2d, so no compiled CUDA extension is needed.
AMD ROCm Optimization
This model export has been adapted and validated for AMD Instinct™ / Radeon™ GPUs running ROCm, as well as AMD CPUs. Key points:
- Validated backends: PyTorch (native ROCm/CUDA, FP32) on GPU and PyTorch (FP32) on CPU.
- No code changes required versus the upstream CenterPose implementation — only environment/runtime configuration differs.
- CPU fallback path supported for environments without a ROCm-capable GPU.
| Runtime | Precision | Backend | Hardware | Notes |
|---|---|---|---|---|
| PyTorch | FP32 | torchvision deformable convolution | AMD CPU | — |
| PyTorch | FP32 | torchvision deformable convolution (ROCm) | AMD Instinct™ / Radeon™ GPU (ROCm) | Same PyTorch code path as CPU; DCNv2 replaced by torchvision.ops.deform_conv2d |
Getting Started
For setup instructions, evaluation scripts, and custom configuration options, see the CenterPose on GitHub.
Model Details
Model Type: 6-DoF object pose estimation (single-stage, keypoint-based)
Model Stats:
- Input:
(1, 3, 512, 512)float32 - Output: 7 heads — hm, wh, hps, reg, hm_hp, hp_offset, scale (float32)
- Precision tested: FP32 (CPU and GPU)
Performance Summary
Higher 3D IoU and AP values mean the model's predicted 3D bounding boxes and poses agree more closely with the reference — 1.0 is perfect agreement. Lower angular errors (azimuth, elevation) and ADD values indicate more accurate pose recovery.
Metrics Explained
| Metric | Description |
|---|---|
| 3D IoU | Intersection-over-Union of predicted vs ground-truth 3D oriented bounding boxes. The primary 3D accuracy measure — higher means the predicted box volume overlaps more closely with ground truth. |
| 2D MPE (px) | Mean Projection Error — average pixel distance between predicted and ground-truth 2D cuboid corner projections. Lower means the projected keypoints align more tightly. |
| Azimuth Error (deg) | Rotation error around the vertical (Y) axis in degrees. Captures how well the model estimates the object's in-plane rotation — the most visible rotational degree of freedom. |
| Elevation Error (deg) | Angular error from the horizontal plane in degrees. Captures the object's tilt relative to the camera — typically smaller than azimuth error for upright objects. |
| Geodesic Error (deg) | Full rotation error measured as the angle of the axis-angle decomposition between predicted and ground-truth rotations. The strictest single-number rotation metric. |
| ADD (normalized) | Average Distance of model-point correspondences between predicted and ground-truth 3D cuboid vertices, normalized by object diameter. Lower means the 3D shape alignment is tighter — values below 0.1 are considered a correct pose. |
| Reprojection Error (px) | PnP solver reprojection error — how closely the recovered 3D pose projects back onto the detected 2D keypoints. A self-consistency check, not relative to ground truth. |
| AP@5°/10°/15°/30° Azimuth | Average Precision at azimuth-error thresholds. AP@15° is the standard reporting threshold — the fraction of detections whose azimuth error is within 15 degrees. |
| AP@3D IoU 25/50/75 | Average Precision at 3D IoU thresholds. AP@50 (IoU ≥ 0.50) is the standard threshold; AP@75 is strict and rewards precise 3D localization. |
| AP@ADD<0.1d | Average Precision where ADD (normalized by diameter) is below 0.1 — the standard ADD threshold from the LineMOD benchmark. |
Accuracy Results
Objectron sample images:
| Device | Precision | 3D IoU | 2D MPE (px) | Azimuth (deg) | Elevation (deg) | AP@15° | AP@IoU50 | ADD |
|---|---|---|---|---|---|---|---|---|
| CPU | FP32 | 1.0000 | 0.00 | 0.00 | 0.00 | 1.0000 | 1.0000 | 0.00000 |
| GPU | FP32 | 0.9587 | 1.22 | 0.12 | 0.14 | 1.0000 | 1.0000 | 0.00960 |
Note: CPU shows perfect scores because ground truth is generated from CPU inference (serving as the reference baseline). GPU results measure cross-device numerical consistency — the extremely low errors confirm near-identical pose recovery across devices.
Dig Deeper
Want to explore the full evaluation scripts, config options, and other AMD-optimized model examples?
📂 View the full project on GitHub
The GitHub repository includes:
- Setup and prerequisites for ROCm environments
- Scripts for the supported runners
- Additional model variants and datasets
- Benchmarking and reproduction instructions