There is a parking lot in the demo image. Buses sit in two diagonal rows.

Oriented R-CNN draws one box per bus, along the row. Faster R-CNN piles extra boxes on those same rows. I ran the official MMRotate weight on the same tile, at the same score. It draws the same pile.

The vertical rows at the edge of the picture come out tidy. The pile appears when long objects sit packed near 45°. The three overlays are below.

One box along the row. The other piles extra boxes on the same buses.

One box along the row. The other piles extra boxes on the same buses.

Three overlays at score ≥ 0.6 Link to heading

Same image, NMS IoU 0.1, score floor 0.6. Look at the two chevron columns in the middle, not the tidy vertical stacks on the edges.

MMRotate Rotated Faster R-CNN 1× zoo — demo.jpg at score ≥ 0.6, NMS 0.1. Duplicate and poorly aligned high-score boxes on the dense diagonal buses.

MMRotate Rotated Faster R-CNN 1× zoo — demo.jpg at score ≥ 0.6, NMS 0.1. Duplicate and poorly aligned high-score boxes on the dense diagonal buses.

OrientedDet Rotated Faster R-CNN 1× Hub — same tile, same knobs. Same kind of clutter: overlaps, awkward angles, occasional small-vehicle on a bus.

OrientedDet Rotated Faster R-CNN 1× Hub — same tile, same knobs. Same kind of clutter: overlaps, awkward angles, occasional small-vehicle on a bus.

OrientedDet Oriented R-CNN 1× Hub — same tile, same knobs. One box per vehicle, angles follow heading.

OrientedDet Oriented R-CNN 1× Hub — same tile, same knobs. One box per vehicle, angles follow heading.

MMRotate’s overlay is orange-on-orange; OrientedDet colour-codes instances. Ignore the palette. The geometry is the point: FRCNN boxes on the diagonal rows sit off-heading and stack on neighbours. Oriented R-CNN does not.

Protocol Link to heading

KnobValue
Imagedemo/demo.jpg, 1024×1024, single forward (already the model canvas)
Score0.3 (MMRotate image_demo default) and 0.6 (OrientedDet FRCNN production.score_threshold)
Rotated NMS IoU0.1
DeviceGPU
StackWeights
MMRotate 0.3.4config rotated_faster_rcnn_r50_fpn_1x_dota_le90.py, zoo rotated_faster_rcnn_r50_fpn_1x_dota_le90-0393aa5c.pth
OrientedDet FRCNNHub rotated_faster_rcnn_dota_le90_1x (rotated_faster_rcnn_r50_fpn_dota_le90_1x-1e3dabeb.pth), recipe configs/rotated_faster_rcnn/dota_le90_1x.json
OrientedDet Oriented R-CNNHub oriented_rcnn_dota_le90_1x

Raising the score from 0.3 to 0.6 barely changes anything. MMRotate keeps the same 100 boxes at both floors (every kept box already scores ≥ 0.6). OrientedDet FRCNN drops one box (102 → 101). Oriented R-CNN is 100 at both. This is not a low-threshold artifact.

Modeln @ 0.6large-vehiclesmall-vehiclemax edge (px)boxes >2× median area
MMRotate FRCNN 1×1009551020
OrientedDet FRCNN 1×1019651040
OrientedDet Oriented R-CNN 1×1009551030

Counts line up. Box sizes line up too: a bus on this tile is ~90–100 px long; no detection is a two-bus swallow. The shared failure is clutter — duplicates, overlaps, misaligned angles — at high score.

Why Faster R-CNN struggles here Link to heading

Rotated Faster R-CNN proposes with a horizontal RPN and pools with horizontal RoIAlign, then regresses a rotated box from that axis-aligned crop. On isolated objects that is often enough, which is why the architecture still posts 73.40% (MMRotate) / 74.42% (OrientedDet ProbIoU) on official DOTA Task 1 — see the ProbIoU write-up and the v0.1.1 zoo / parity note. The mess appears when many elongated boxes sit at ~45° in a tight pack: the RoI is a horizontal window over several neighbours, and the head has to invent orientation from a crop that was never aligned to the vehicle. Oriented R-CNN uses oriented proposals and oriented RoIAlign, so the second stage sees a box already rotated with the bus. That is the whole visual difference on this tile.

A zoo mAP does not mean tidy boxes on every hard tile. The optical demo used 3× Faster R-CNN on a related vehicle scene; this check is the 1× zoo — official MMRotate and the OrientedDet Hub slug — on the classic demo.jpg.

What this run did not show Link to heading

Some earlier OrientedDet FRCNN screenshots looked like one OBB covering two neighbouring buses. This verification did not reproduce that. Max edge is 102–104 px; zero boxes exceed 2× median area, on MMRotate, OrientedDet FRCNN, and Oriented R-CNN. If a past run still showed swallowing boxes, re-check that checkpoint / NMS / viz path — it is not what Hub 1× and the MMRotate 1× zoo do on demo/demo.jpg today.

Reproduce Link to heading

From an oriented-det checkout:

odet pretrained download rotated_faster_rcnn_dota_le90_1x
odet pretrained download oriented_rcnn_dota_le90_1x

odet image-demo demo/demo.jpg hf://rotated_faster_rcnn_dota_le90_1x \
  --score-thr 0.6 --nms-thr 0.1 --out-file odet_frcnn_score0.6.png

odet image-demo demo/demo.jpg hf://oriented_rcnn_dota_le90_1x \
  --score-thr 0.6 --nms-thr 0.1 --out-file odet_orcnn_score0.6.png

MMRotate 0.3.4, same image and knobs:

python demo/image_demo.py \
  /path/to/oriented-det/demo/demo.jpg \
  configs/rotated_faster_rcnn/rotated_faster_rcnn_r50_fpn_1x_dota_le90.py \
  /path/to/data/rotated_faster_rcnn_r50_fpn_1x_dota_le90-0393aa5c.pth \
  --score-thr 0.6

Written on October 26, 2026 by Jeff Faudi. Link to heading