A detector that draws tight boxes around upright pedestrians can still fail badly on a pallet skewed 30 degrees on a conveyor. The model is not confused about what the object is — the class score is fine. The problem lives in one specific component: the detection head, and the box parameterisation it was built to regress. If that head only knows how to emit four numbers, no amount of retraining teaches it to describe a rotated part, because there is no output slot for an angle. That is the quiet trap in a lot of object-detection projects. Teams treat the head as a black box bolted onto the backbone and assume box geometry is simply whatever the model happens to produce. It holds right up until production geometry stops being upright and axis-aligned — and by then the architectural decision was already made, months earlier, when someone picked an off-the-shelf detector without checking what its head outputs. What is a detection head, and how does it differ from the backbone and neck? A modern single-stage detector is usually described in three parts. The backbone — often a 2D convolutional network like a ResNet or a CSPDarknet variant — extracts feature maps from the input image. The neck — a feature-pyramid network or PANet-style aggregator — fuses those features across scales so that both small and large objects have representations to work with. The head is the final stage: it takes the fused features and turns them into the actual predictions you consume downstream. The distinction matters because the three parts answer different questions. The backbone answers what visual patterns are present. The neck answers at what scale. The head answers where, how confident, and which class — and, critically, in what geometric form. The 2D convolutional network that forms the perception backbone has no opinion about whether your boxes are rotated; that decision is not encoded in the features. It is encoded in the head’s output layer and the loss that trains it. This is why “the model doesn’t produce oriented boxes” is almost never a backbone problem. Swapping backbones for a stronger feature extractor changes accuracy, not geometry. The geometry is a property of the head. What does a detection head regress, and how do the outputs combine? For each candidate location — an anchor box, an anchor point, or a query in a transformer-style detector like RT-DETR — the head produces a small vector of numbers. In the common axis-aligned case, those numbers fall into three groups: Box coordinates. Four values describing the box. Depending on the parameterisation, that is either the two corners (x1, y1, x2, y2) or a centre plus size (cx, cy, w, h). This is a regression output — continuous numbers, trained with a regression loss such as smooth L1 or a Complete IoU loss. Objectness / confidence. A single score estimating whether this location contains an object at all, independent of which class. In practice this is what gets thresholded first to prune the flood of candidate detections. The relationship between that score and reliability is subtle — we cover it in what a confidence score in computer vision actually means. Class scores. One score per class, describing which category the object belongs to. At inference, the head runs this per-location prediction densely across the feature map, and the raw output is a large set of overlapping candidate boxes. Non-maximum suppression then collapses them: for each cluster of overlapping boxes above the confidence threshold, keep the strongest and discard the rest. The final list of boxes you feed to a tracker or a business rule is what survives that suppression step. The key point for this discussion: the coordinate group is the geometry group. Its width — how many numbers it contains — is what decides whether your boxes can rotate. How does the head decide axis-aligned (4 values) or oriented (5 values)? An axis-aligned bounding box (AABB) is defined by four numbers. An oriented bounding box (OBB) adds a fifth: an angle. That single extra output value is the entire difference between a detector that can describe a rotated part and one that cannot. Here is the reframe that saves projects. The choice between four and five is not a runtime toggle, not a config flag, not something you switch on when you notice your parts are rotated. It is an architectural property of the head’s regression branch — the shape of the final convolution’s output channels and the loss that supervises them. A four-value head has no angle term. There is no learned parameter that represents orientation, so there is nothing to fine-tune into producing one. Oriented detectors — the family behind rotated-detection benchmarks on aerial and industrial imagery — build the angle in from the start. The regression branch outputs five values, the loss accounts for angular error (with its own headaches around angle periodicity and the boundary discontinuity at ±90°), and the training annotations carry rotation. A conventional COCO-style detector does none of this because the COCO annotation format behind bounding-box detection only stores axis-aligned boxes to begin with. Quick answer: AABB head vs OBB head Property AABB head OBB head Regression outputs per location 4 (box) + objectness + classes 5 (box + angle) + objectness + classes Represents rotation No angle term exists Angle is a first-class output Training annotations needed Axis-aligned boxes Rotated boxes (extra annotation cost) Loss function IoU / L1 on 4 coords Adds angular loss term, handles periodicity Retrofit path Re-architect regression branch + re-annotate — Best fit Upright, sparse targets Rotated, densely packed, elongated targets The rows on annotation and retrofit are where the money is. Choosing the wrong side of this table early does not just cost accuracy — it costs a second annotation pass and a modified training pipeline later. Why does the wrong parameterisation cost a re-annotation pass? Picture a line-side inspection project that started with an off-the-shelf AABB detector because it was fast to stand up and the first sample images happened to show parts lying flat and square. It works in the demo. Then the real conveyor arrives, parts tumble and settle at arbitrary angles, and the tight-fit requirement bites: an axis-aligned box around a part rotated 45 degrees encloses a large amount of background, IoU against the true footprint drops, and downstream logic that assumed a snug box starts mis-measuring. The instinct is to “just make it output rotated boxes.” But the head has no angle term, so this is not a fine-tune. It is three linked pieces of unplanned scope: New annotations. Existing labels are axis-aligned rectangles. Oriented training needs rotated-box labels — a fresh annotation pass over the dataset, or a re-labelling of what you have. This is where rotated bounding box detection and when orientation actually matters becomes a project decision rather than a modelling detail. A modified regression branch. The head’s output channels change, the loss changes to include angular error, and the model retrains from a changed architecture. Re-validation. Metrics computed against axis-aligned ground truth no longer mean what they did; IoU and mAP have to be recomputed against oriented ground truth, which shifts the numbers you report. In our experience across industrial-inspection scoping, this is one of the most common mid-project reworks in detection pipelines, and it is entirely avoidable — the geometry question is answerable at feasibility time, before a single label is drawn. Naming the cost early is the whole point: it turns a surprise into a line item. The measurable payoff of getting it right up front is a shorter path to tight localisation — higher IoU at the same recall on rotated or densely packed targets — without a second annotation pass. (This is an observed engagement pattern in CV feasibility work, not a benchmarked rate.) Can an off-the-shelf head be modified to output oriented boxes? Sometimes, and it depends on how the detector was built. Some frameworks ship both an AABB and an OBB variant of the same head — YOLO-family implementations increasingly include an oriented mode, and choosing it at model-definition time is straightforward. In that case you are selecting a different head, not modifying one: the OBB variant is a distinct architecture with its own five-value regression branch and its own loss, and you point your training at rotated annotations. Where the detector only exposes an axis-aligned head, “modifying” it means editing the regression branch — adding the angle channel, wiring in an angular loss, and dealing with the angle-boundary discontinuity — then retraining on rotated labels. That is a real engineering task, not a switch. It is feasible, but it lands the same annotation and re-validation costs as switching to a purpose-built oriented detector, so the honest comparison is usually pick the right head now versus pay to retrofit later, not modify versus replace. A related escape hatch worth naming: promptable segmentation. If you can get a tight mask of the object, you can derive an oriented box from the mask’s minimum-area rectangle — the approach behind SAM-derived oriented boxes feeding detection. That sidesteps the angle-regression problem by not regressing an angle at all, at the cost of running a segmentation stage. It is a legitimate alternative when annotation budget for rotated boxes is the binding constraint. FAQ What should you know about a detection head in practice? The detection head is the final stage of a detector. It takes fused feature maps from the backbone and neck and, for each candidate location, regresses box coordinates, an objectness score, and per-class scores. In practice it is the component that turns learned features into the boxes you actually consume, and its output layer is where box geometry is fixed. What is a detection head, and how does it differ from the backbone and neck of a detector? The backbone extracts visual features, the neck fuses them across scales, and the head produces the final predictions — where, how confident, which class, and in what geometric form. The distinction matters because box geometry is a property of the head’s output layer and loss, not of the backbone’s features. Swapping backbones changes accuracy, not whether boxes can rotate. How does the detection head decide whether boxes are axis-aligned (4 values) or oriented (5 values with an angle)? An axis-aligned box needs four coordinate values; an oriented box adds a fifth value for the angle. Whether the head emits four or five is an architectural property of its regression branch and loss, not a runtime toggle. A four-value head has no angle parameter to fine-tune, so it cannot be made to output rotation without changing its architecture. What outputs does a detection head regress — coordinates, objectness, and class scores — and how do they combine? Per candidate location the head regresses box coordinates (4 or 5 values), a single objectness score, and one score per class. At inference these run densely across the feature map, objectness thresholds prune weak candidates, and non-maximum suppression collapses overlapping boxes into the final detection list fed downstream. Why does choosing the wrong head parameterisation force costly re-annotation and retraining later? An AABB head has no angle term, so producing oriented boxes is not a fine-tune — it requires a modified regression branch, a new angular loss, and rotated-box annotations the original dataset does not contain. That means a fresh annotation pass, retraining from a changed architecture, and re-validation against oriented ground truth. Deciding the parameterisation at feasibility time avoids all of it landing as unplanned scope. Can an off-the-shelf detection head be modified to output oriented boxes, or does it require a different head? If the framework ships an OBB variant, you select that distinct head and train it on rotated labels — that is a choice, not a modification. If only an axis-aligned head exists, adding the angle channel, angular loss, and rotated annotations is a real engineering task carrying the same annotation and re-validation costs as adopting a purpose-built oriented detector. Where does that leave the practical decision? The detection head is the design surface where the AABB-versus-OBB call physically lives, so treat it as one — inspect the head’s output parameterisation against your production geometry before committing, not the geometry your first sample images happened to show. For line-side inspection of parts that will not stay square, that inspection belongs in a computer vision feasibility assessment at the scoping stage, alongside the annotation-budget question it drives. The failure class to watch for is a geometry mismatch discovered after annotation has already been paid for once.
