Bounding Box Augmentation in Detection: Formats, Errors, and Best Practices

An article published on the Habr platform is devoted to a common and often overlooked reason for failures in training object detection models: not the network architecture itself, but what happens to bounding boxes (bbox) — annotation rectangles — after augmentations are applied.

Where markup most often breaks

The author lists typical errors that do not cause code to crash with an exception, but invisibly corrupt the training dataset: incorrectly specified coordinate format (coord_format), confusion between normalized and absolute coordinates, overly aggressive crop operations, and the appearance of empty boxes after filtering objects that have gone beyond the frame. Such errors do not cause an explicit pipeline failure — the model simply trains on distorted markup, and the resulting quality drop is attributed to the architecture or hyperparameters, though the cause lies in preprocessing.

The problem is aggravated by the fact that different datasets and different libraries historically use different conventions for storing bbox coordinates: sometimes it's absolute pixel coordinates of the top-left and bottom-right corners, sometimes normalized values from zero to one relative to image dimensions, and sometimes — coordinates of the box center along with width and height. It's enough to confuse these representations once when passing markup between pipeline stages for training to continue without errors, but the model learns to find objects not where they actually are in the image.

• Library being discussed: Albumentations
• Supported bbox formats: COCO, YOLO, pascal_voc
• Key parameters: A.BboxParams, min_area, min_visibility
• Typical problem: RandomCrop often works poorly for detection tasks
• Source: Habr

How to properly configure Albumentations?

The article breaks down the practical side of the matter using the example of the Albumentations library — one of the most common image augmentation tools in computer vision. It discusses the bbox formats supported by the library, correct configuration of the A.BboxParams parameter, as well as the purpose of the min_area and min_visibility parameters, which determine the minimum size or visibility of an object after transformation for the bbox to still be considered valid rather than discarded or distorted.

Albumentations is widely used precisely because it can synchronously transform an image and its associated markup — when rotating, flipping, or changing the scale of an image, the library automatically recalculates the coordinates of all bboxes on it, relieving the developer from writing this logic manually. But this same automation becomes a source of problems if the A.BboxParams parameters are set incorrectly: the library will not produce an error, it will simply recalculate the coordinates in accordance with the specified (albeit incorrect) format, and the developer will get a formally correct but actually corrupted augmentation pipeline.

Why RandomCrop is not always a safe choice

Special attention in the material is devoted to why ordinary RandomCrop — a popular augmentation for image classification — often turns out to be a poor solution specifically for object detection. When a frame is randomly cropped, objects at the edges may be partially or completely cropped, and without careful subsequent filtering through min_area and min_visibility, the markup either contains distorted boxes or entirely empty boxes, which the model perceives as valid training data.

The material is addressed to those who work with popular markup formats COCO, YOLO, and pascal_voc and want to understand why augmentations "don't work" — that is, why adding standard out-of-the-box transformations does not improve, and sometimes even worsens, model metrics. The practical value of such a breakdown is that it shifts the debugging focus from hyperparameters and architectures to a much more mundane, yet frequent source of problems — the correctness of geometric transformations of markup, which computer vision specialists often underestimate at the start of a project.

For teams working with industrial markup datasets, such a breakdown is especially valuable at the stage of transitioning between formats: for example, when data is marked in COCO format, but training is conducted on an architecture expecting YOLO format, or vice versa. Manual conversion between such formats is a frequent source of elusive errors, and the material essentially offers a checklist of things worth checking before attributing low model quality to the architecture itself or lack of data.