YOLO26 OBB: Optimized for AMD ROCm

YOLO26 OBB is a real-time oriented bounding box detection model that detects and localizes rotated boxes across 15 DOTA categories in a single forward pass, built for aerial/satellite imagery where objects appear at arbitrary orientations. This repository packages inference for oriented object detection using ONNX Runtime, exported and validated for AMD ROCm so it runs efficiently on AMD GPUs, CPUs, and NPUs.

This is based on the implementation of YOLO26 found here. This repository contains configurations and scripts optimized for AMD® ROCm™ platforms. You can use the yolo26_obb AMD scripts to reproduce results or export with custom configurations. More details on model performance can be found here.

Task Overview

Task: Oriented bounding box (OBB) detection

Dataset: DOTAv1 val (458 pre-sliced 1024×1024 tiles, 15 categories)

Output metrics: mAP50, mAP50-95, per-class AP50

Model variants: Default is n. Override with MODEL_SIZE=n/s/m/l/x.

GPU/NPU note: MIGraphX runtime-quantizes a single FP32 ONNX model to cover all GPU precisions. NPU execution requires BF16 — VitisAI quantizes the FP32 ONNX internally at runtime using configs/vitisai/obb_bf16.json.

AMD ROCm Optimization

This model export has been adapted and validated for AMD Instinct™ / Radeon™ GPUs running ROCm, as well as AMD CPUs and AMD Ryzen AI NPUs. Key points:

Validated backends: ONNX Runtime across CPU (FP32), GPU (MIGraphX Execution Provider — FP32/FP16/BF16/INT8), and NPU (VitisAI Execution Provider — BF16, auto-quantized internally).
No code changes required versus the upstream Ultralytics YOLO26 OBB implementation — only environment/runtime configuration differs.
GPU first run: MIGraphX compiles the model on first use (30+ minutes); compiled kernels are cached and reused afterwards.
Output format is xywhr (center, size, rotation angle in radians) or xyxyxyxy (four corner points); post-processing applies rotated NMS rather than standard axis-aligned NMS.

Runtime	Precision	Backend	Hardware	Notes
ONNX Runtime	FP32	CPU Execution Provider	AMD CPU	—
ONNX Runtime	FP32 / FP16 / BF16 / INT8	MIGraphX Execution Provider	AMD Instinct™ / Radeon™ GPU (ROCm)	First run pays a 30+ minute graph-compilation cost
ONNX Runtime	BF16	VitisAI Execution Provider	AMD Ryzen AI NPU	Auto-quantized internally

Getting Started

For setup instructions, evaluation scripts, and custom configuration options, see the yolo26_obb on GitHub.

Model Details

Model Type: Oriented bounding box detection (single-pass CNN detector with rotated-box head)

Base Model: YOLO26 OBB (Ultralytics), size n default

Model Stats:

Input: (1, 3, 1024, 1024) float32
Output: (1, 300, 7) float32
Precision tested: FP32 (CPU); FP32, FP16, BF16, INT8 (GPU); BF16 (NPU)

Accuracy Pipeline

Rotated-mAP evaluation is fully implemented — make eval-<device> runs inference across all 458 DOTAv1 val tiles and computes rotated mAP via Ultralytics' ap_per_class + batch_probiou, the same primitives YOLO.val() uses internally (the practical standard for rotated boxes, since pycocotools only handles axis-aligned boxes).

Higher mAP means the model's predicted rotated boxes and classes agree more closely with ground truth across the dataset — 1.0 is perfect detection, 0.0 means no correct detections. For DOTA-scale aerial OBB, mAP50 above ~0.5 is considered strong.

Metrics Explained

Metric	Description
mAP50	AP at a single, looser IoU threshold of 0.50 — a predicted rotated box only needs to overlap ground truth by 50% to count as correct. Reflects "did it find and roughly orient the object"; typically the highest of these numbers and forgiving of small size/angle error.
mAP50-95	Mean AP averaged across IoU thresholds 0.5–0.95 — the strict, holistic accuracy number. Rewards precise box size, position, and angle, so it sits well below mAP50; a large gap between the two means objects are found but loosely localized.
Per-class AP50	mAP50 broken down over the 15 DOTA categories — exposes class-specific weaknesses (e.g. rare or tiny classes like small-vehicle or storage-tank) that a single aggregate score would hide.

Evaluation resolution (imgsz): OBB evaluates at the model's native 1024×1024 (DOTA convention — DOTA val tiles are large and objects are tiny, so 1024 is required; evaluating at 640 silently drops ~12 mAP50 points of recall). At matching imgsz, the ONNX runner reproduces the PyTorch YOLO.val() oracle within ~1 pt.

Accuracy Results

Full Dataset Evaluation (DOTAv1 val, 458 tiles) — MODEL_SIZE=n:

Device	Precision	mAP50	mAP50-95	vs. CPU FP32
CPU	FP32	60.4%	45.4%	— (baseline)
GPU	FP32	61.4%	46.6%	+1.1
NPU	BF16	6.7%	5.8%	-53.7

Note: YOLO26 OBB is an end2end (NMS-free) head whose ONNX graph emits a fixed top-k ranked set per image (default 300). Dense tiles can exceed that count, capping recall — eval-* targets automatically use an eval export with the cap raised (EVAL_MAX_DET, default 2000).

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
Full DOTAv1 val evaluation pipeline via Ultralytics' rotated-mAP primitives
Per-operator latency profiling scripts (including NPU AI Analyzer integration)
Benchmarking and reproduction instructions across CPU, GPU, and NPU

Downloads last month: -; Downloads are not tracked for this model. How to track