Bounding Box Augmentation in Object Detection: Formats, Pitfalls and Best Practices

Habr has published an article on a common and easily overlooked cause of failures when training object detection models: not the network architecture itself, but what happens to bounding boxes (bboxes), the rectangular annotation frames, after augmentations are applied.

Where annotations break most often

The author lists typical errors that do not crash the code with an exception but quietly corrupt the training set: an incorrectly specified coordinate format (coord_format), confusion between normalized and absolute coordinates, overly aggressive crop operations, and empty boxes appearing after objects that fall outside the frame are filtered out. These errors cause no visible pipeline failure. The model simply trains on distorted labels, and the resulting drop in quality is blamed on the architecture or hyperparameters, even though the cause lies in preprocessing.

The problem is compounded by the fact that different datasets and libraries have historically used different conventions for storing bbox coordinates: some use absolute pixel coordinates of the top-left and bottom-right corners, some use normalized values from zero to one relative to the image size, and others use the box center plus its width and height. Mixing up these representations just once while passing annotations between pipeline stages is enough for training to keep running without errors while the model learns to find objects where they are not actually located in the image.

• Library examined: Albumentations
• Supported bbox formats: COCO, YOLO, pascal_voc
• Key parameters: A.BboxParams, min_area, min_visibility
• Typical problem: RandomCrop is often a poor fit for detection tasks
• Source: Habr

How do you configure Albumentations correctly?

The article covers the practical side using Albumentations, one of the most widely used image augmentation tools in computer vision. It looks at the bbox formats the library supports, the correct configuration of A.BboxParams, and the role of min_area and min_visibility, which determine the minimum size or visibility an object must retain after a transform for its box to still count as valid, rather than being discarded or distorted.

Albumentations is widely used precisely because it transforms an image and its associated annotations in sync: when an image is rotated, flipped or rescaled, the library automatically recalculates the coordinates of every bbox on it, sparing developers from writing that logic by hand. But the same automation becomes a source of problems if the A.BboxParams settings are wrong: the library will not raise an error, it will simply recalculate coordinates according to the specified (even if incorrect) format, and the developer ends up with an augmentation pipeline that appears to work but is in fact broken.

Why RandomCrop is not always a safe choice

The article pays particular attention to why plain RandomCrop, a popular augmentation for image classification, often turns out to be a bad choice for object detection. When a frame is randomly cropped, objects at the edges can be partially or fully cut off, and without careful follow-up filtering via min_area and min_visibility, the annotations are left with distorted or even empty boxes that the model treats as valid training data.

The material is aimed at people working with the popular annotation formats COCO, YOLO and pascal_voc who want to understand why augmentations "don't work", that is, why adding standard out-of-the-box transforms does not improve model metrics and sometimes even worsens them. The practical value of this analysis is that it shifts debugging focus from hyperparameters and architectures to a far more mundane but common source of problems: the correctness of geometric transformations applied to annotations, which computer vision specialists often underestimate at the start of a project.

For teams working with industrial annotation datasets, this kind of walkthrough is especially useful when converting between formats: for example, when data is labeled in COCO format but training runs on an architecture that expects YOLO, or vice versa. Manual conversion between such formats is a frequent source of hard-to-catch errors, and the article essentially offers a checklist of things to verify before blaming poor model quality on the architecture itself or on a lack of data.