Ask a perception engineer what a detection box represents and most will describe a rectangle drawn parallel to the image axes: two corners, a class label, a confidence score. That is an axis-aligned bounding box, and it is what nearly every detection benchmark rewards. It works well right up until a vehicle is mid-turn, a cyclist crosses diagonally, or a target sits obliquely in the frame of a corner-mounted sensor. In those cases the axis-aligned rectangle either swallows empty space around the object or clips it — and either way, it says nothing about which way the object is pointing. A rotated bounding box fixes the second problem, and it is the more important one. Heading — the orientation of the object relative to the scene — is not a cosmetic detail in driving. It is the input a planner uses to predict where a car will be in two seconds. An axis-aligned box that scores a perfect intersection-over-union can still be silent about heading, and silence there is a failure that no headline accuracy number will surface. What is a rotated bounding box, and what does it represent in practice? An axis-aligned box is defined by four numbers: a center (or corner) plus a width and height, all measured against the image or grid axes. A rotated — sometimes called oriented — bounding box adds one more degree of freedom: an orientation angle. The box is now (cx, cy, w, h, θ), where θ rotates the rectangle so its edges align with the object rather than the frame. That single extra parameter changes what the detection means. An axis-aligned box answers “is there an object, and roughly where?” A rotated box answers “where is it, how big is it, and which way is it facing?” For a parked car photographed head-on, the two representations are nearly identical. For a car turning left across an intersection, they diverge sharply: the axis-aligned box grows to a large square that half-covers the crosswalk, while the rotated box stays tight to the vehicle’s actual footprint and encodes its heading. This is the same distinction we draw when we explain what a detection label actually represents in ASIL-grade perception evidence — a box is a claim about the world, and a rotated box makes a stronger, more falsifiable claim than an axis-aligned one. Oriented boxes appear across the detection literature under names like OBB (oriented bounding box) in aerial imagery, and increasingly in automotive stacks where bird’s-eye-view representations demand heading. If you have worked with rotated-box heads in frameworks like PyTorch-based detectors or the oriented variants of YOLO, you have seen the angle regressed as a separate output branch alongside the extent regression. Axis-aligned versus oriented: when does each one fail? The failure modes are not symmetric, which is why the choice is not arbitrary. Property Axis-aligned box Rotated (oriented) box Parameters cx, cy, w, h cx, cy, w, h, θ Encodes heading? No Yes Tightness on angled objects Loose — over-covers empty space Tight — follows the object Benchmark behaviour on head-on samples Excellent Excellent Behaviour on turning / oblique views Degrades quietly, no heading signal Degrades measurably, heading still reported Typical failure Clips or over-covers; heading unrepresented Angle ambiguity (e.g. 180° flips), higher annotation cost IoU metric Standard axis-aligned IoU Rotated-IoU (accounts for θ) Axis-aligned boxes fail silently. On a benchmark dominated by well-framed, mostly head-on samples, they look fine — and that is exactly the trap. The metric rewards the easy distribution and never asks about the angled cases. Rotated boxes fail loudly: their characteristic error is angular ambiguity, most notoriously the 180° flip where a model confuses front for back. That is a real problem, but it is a visible one. You can measure it, bound it, and decide whether it matters for your planner. A failure you can see is worth more than a failure you cannot. The general lesson here echoes what we have written about the perception failure modes that survive benchmarks: the benchmark’s framing selects for the cases where the cheaper representation looks adequate. The long tail — angled crossings, corner-sensor obliquity, mid-maneuver vehicles — is where the representation choice actually bites. How is orientation error measured? Two metrics carry most of the weight, and they answer different questions. Rotated-IoU is the direct extension of intersection-over-union to oriented rectangles. Instead of comparing two axis-aligned boxes, it computes the overlap of two rotated polygons, so a prediction that is the right size and position but rotated 30° off will score lower than an axis-aligned IoU would suggest. This keeps the extent-and-orientation claim honest as a single overlap number. Angular (heading) error isolates orientation on its own — typically the absolute difference between predicted and ground-truth θ, reported in degrees. Separating it out matters because rotated-IoU can mask a heading problem: a nearly-square object can be badly mis-oriented while still overlapping well. For anything where the planner consumes heading — vehicles, especially — angular error is the metric that speaks to the downstream consumer directly. Here is the point that a single mAP number will never carry: orientation error is a per-scenario-class property, not a scalar. A model can have low mean angular error overall while concentrating almost all of its heading mistakes in exactly the turning and oblique-view cases that dominate real driving risk. Averaging washes that out. You measure orientation error where it concentrates, or you do not really know it. Which scenario classes deserve their own orientation measurement? At minimum, break heading accuracy out for the classes where axis-aligned framing and benchmark distribution diverge from production: Turning vehicles — objects mid-maneuver, where heading is changing and most valuable to the planner. Angled crossings — pedestrians and cyclists crossing diagonally rather than perpendicular to travel. Oblique corner-sensor views — targets seen from a corner-mounted camera at a steep angle, the case least represented in head-on benchmark samples. Occluded targets — where only part of the object is visible and orientation must be inferred from a fragment. Reporting a single number across all four hides the one you most need to see. This is the same reasoning we apply to what each performance metric actually proves — the aggregate is a convenience, not the evidence. Why does heading matter for downstream planning? The planner does not consume boxes for their own sake. It consumes them to predict motion. Heading is the strongest single cue for where a dynamic object is going, and a mis-estimated heading propagates into a wrong trajectory prediction, which propagates into a wrong decision about whether to yield, brake, or proceed. An axis-aligned box hides this failure completely. It carries no heading, so the planner either has no orientation input from detection or synthesizes it downstream from tracking — which pushes the error into a different subsystem where it is harder to attribute. When a rotated-box head is available, heading is a first-class detection output, and its error is measurable at the point where it is produced rather than inferred two stages later. In our experience auditing perception stacks, orientation error that is invisible at the detection layer tends to resurface as unexplained planning jitter — and by then it is expensive to trace back. This connects to how bird’s-eye-view detection changes the evidence story, where oriented boxes in the BEV frame are the natural representation for exactly this reason. How does rotated-box error fit a robustness assessment? A single benchmark score is a summary, not a safety argument. A per-scenario-class robustness assessment treats each scenario class as its own evidence line: rotated-IoU and angular error reported separately for turning, angled-crossing, and corner-sensor cases, alongside the localisation delta between the benchmark’s framing and the oblique real-world views the vehicle actually sees. That structure is what turns “the model scores 0.8 mAP” into “the model’s heading error on turning vehicles is bounded to X degrees under conditions like the ones we tested” — a claim a release reviewer can act on. This is exactly the kind of per-scenario-class metric that our computer vision engineering practice builds into a robustness audit, and it is the metric family that the Production AI Monitoring Harness operationalises into a validation evidence pack. The cross-vertical validation-package reference we maintain formalises orientation error as one such line item, so a reviewer sees not a headline number but a defensible per-class breakdown. FAQ How does rotation bounding box actually work? A rotated bounding box adds an orientation angle θ to the usual center-plus-extent parameters, giving (cx, cy, w, h, θ). In practice this lets the box stay tight to an object that is not aligned with the image axes and, more importantly, encodes which way the object is facing — its heading — which an axis-aligned box cannot represent. What is the difference between an axis-aligned bounding box and a rotated (oriented) bounding box, and when does each fail? An axis-aligned box has four parameters and no heading; a rotated box adds the angle and captures orientation. Axis-aligned boxes fail silently on angled, turning, and obliquely-viewed objects — they over-cover or clip and carry no heading. Rotated boxes fail more visibly, typically through angular ambiguity such as 180° flips, but that failure is measurable rather than hidden. How is a rotated bounding box represented, and how is orientation error measured? It is represented as extent plus an orientation angle. Orientation error is measured with rotated-IoU, which computes overlap between oriented polygons and so penalises rotation mistakes, and with angular (heading) error, the difference in degrees between predicted and true θ. The two are complementary: rotated-IoU can mask a heading problem on near-square objects, so angular error is reported separately. Why does heading estimation matter for downstream planning, and where do axis-aligned boxes hide that failure? The planner uses heading to predict where a dynamic object is going, so a mis-estimated heading becomes a wrong trajectory and a wrong yield/brake decision. Axis-aligned boxes carry no heading at all, so the error either never appears at the detection layer or gets pushed into tracking, where it is harder to attribute. Which scenario classes should rotated-box accuracy be measured against separately? At minimum: turning vehicles, angled crossings (diagonal pedestrian/cyclist paths), oblique corner-sensor views, and occluded targets. These are the cases where benchmark framing diverges most from production distribution, and a single averaged number hides the class where orientation error concentrates. How does rotated-box orientation error fit into a per-scenario-class robustness assessment rather than a single benchmark score? Each scenario class becomes its own evidence line, with rotated-IoU and angular error reported separately, plus the localisation delta between benchmark framing and real oblique views. That turns a headline mAP into per-class, bounded claims about heading accuracy that a reviewer can evaluate against the distribution the vehicle actually drives in. What evidence about orientation accuracy should a release reviewer expect in a validation pack before shipping? A reviewer should expect per-scenario-class rotated-IoU and angular-error breakdowns — not a single aggregate — covering the turning, angled-crossing, and corner-sensor cases, with the benchmark-to-production localisation delta made explicit. This is the evidence a validation pack should contain so orientation accuracy is a bounded, defensible claim rather than an assumption. The temptation with any new representation is to treat the extra parameter as a free upgrade. It is not: rotated boxes cost more to annotate, introduce angular ambiguity, and demand a metric — rotated-IoU plus separated angular error — that most benchmarks do not report by default. The reason to pay that cost is not the box itself but what it makes visible. If your perception stack cannot tell you its heading error on turning vehicles, the honest answer is that you do not know how it behaves on the cases that matter most — and that gap is exactly what a per-scenario-class robustness audit exists to close.
