OBB - Ground truth labels getting distored and inaccurate in train batch images (with incorrect orientations and offsets)

[farhanrw]

Search before asking

• I have searched the YOLOv8 issues and found no similar bug report.

YOLOv8 Component

Train

Bug

Hi, firstly thanks to the whole team for the amazing work in developing yolov8 (especially with OBB). I am still seeing issues with OBB with and without data augmentation. I am attaching two images as an example. When using OBB, I can constantly see the ground truth overlays are sometimes not oriented and sometimes not fitting around all the edges. By cases I mean from what I see in train_batch0,1 and 2 inside the train folder.

To illustrate this problem clearly, I created a dummy dataset of 4-5 images with a colorful rectangle sitting at the center and labeled the images. I labeled these myself and exported them using Roboflow and Yolov8-obb. As you can see from the images, the square shapes are not always showing correctly oriented bounding boxes. My dataset just has 4-5 images and I have manually hand-labeled them correctly. This does not happen when I use the regular detection model without OBB. Using OBB and additional rotation augmentation distorts the boxes, especially at the edges.

These attached images are not predictions, but rather train_batch images.

A few more with a larger resolution. You can also see how some of these boxes are not tight and seem to have an offset (bottom right one as an example)

Environment

No response

Minimal Reproducible Example

No response

Additional

No response

Are you willing to submit a PR?

• Yes I'd like to help by submitting a PR!

[glenn-jocher]

Hello! Thanks for sharing your observations with the OBB (Oriented Bounding Box) functionality in YOLOv8, and for providing detailed examples from your experiment. 😊 Your contribution is invaluable to refining and improving the model.

From your description, it sounds like the ground truth overlays for OBBs are not aligning as expected, particularly with orientation and fitting issues, notably after applying rotation augmentation. This could be influenced by how augmentation transformations are applied or interpreted for OBBs compared to standard bounding boxes.

To address this, could you please try adjusting the augmentation parameters in your training configuration? Specifically, you might want to experiment with modifying or temporarily disabling rotation augmentation to assess its direct impact on OBB distortion.

For example, in your dataset's YAML configuration, you can adjust the degrees parameter under augmentations to a lower value or set it to 0 to disable rotation:

augment:
  degrees: 0  # Adjust or set to 0 to disable rotation augmentation

This step will help isolate if the issue stems directly from how the model handles rotation augmentations with OBBs.

Additionally, it's worth ensuring that your dataset annotations for OBBs are in the expected format YOLOv8 requires. A minor discrepancy in annotation format could lead to unexpected behaviors.

Lastly, if the issue persists, it might be beneficial to share a snippet of your dataset (if possible) and the specific configuration settings you're using. That information could help the community or the dev team to replicate the scenario more accurately and provide further assistance.

Thank you for your detailed report, and we look forward to assisting you in resolving this matter! 🚀

[glenn-jocher]

@farhanrw can you share your dataset in a zip here in this issue please to allow us to reproduce?

@Laughing-q user here is saying that rotation augmentation is not working well with OBB, can you check this out?

[Laughing-q]

@glenn-jocher @farhanrw Guys the final augmented oriented bounding boxes are determined by the algorithm cv2.minAreaRect() that we uses in xyxyxyxy2xywhr function.

ultralytics/ultralytics/utils/ops.py

Line 539 in 5a82b51

(x, y), (w, h), angle = cv2.minAreaRect(pts)

For objects that are cut-off a lot by augmentations, current final boxes(shown above) might be the best the algorithm can do.
I've already figured a solution to alleviate the issue which showed better visual results in my tests on DOTAv1 dataset, that is to sample more(4 --> 100) coordinates(so that cv2.minAreaRect() could get xywhr from a more dense candidate) for each oriented bounding boxes to get better final results.

ultralytics/ultralytics/data/dataset.py

Line 219 in 5a82b51

segment_resamples = 100 if self.use_obb else 1000

@farhanrw From your samples the solution is not working very well on your dataset, could you upload a few samples here if you don't mind? so that we can try to figure a better solution.

[farhanrw]

@glenn-jocher @Laughing-q Sorry for the late reply. Yes sure, this is a dummy dataset that I have created and can share it.

Testing-squares.zip

[farhanrw]

Also it might just not be related to the rotation augmentation. If you set the degrees to 0 but still have mosaic on then you can also notice that the mosaiced images where there are bounding boxes at the edge of the images, the boxes seem to have an offset, as in it does not go over the edge of the object accurately. Again this can be reproduced but using 0 deg rotation augmentation and using mosaic.

In this image, the bottom two ROIs show this issue. The bottom-left one does not cover the partially visible object properly, and the bottom-right does not even have the bounding box.

Another example where you can the bottom right two ROIs do not cover the shape edge to edge ---

[glenn-jocher]

@farhanrw thanks for the additional observations, it’s incredibly helpful! 🙏 Your insights on the potential impact of mosaic augmentation, even with rotation disabled (degrees set to 0), shine a light on a broader aspect of how augmented bounding boxes are handled. It seems that objects at the edges of mosaiced images might not get their bounding boxes accurately fitted, impacting the precision of OBB.

Investigating the behavior with mosaic augmentation, especially at the image edges, is definitely on our radar now. The examples you've provided clearly illustrate the problem. It's possible that the algorithm’s handling of edge cases (literally!) in mosaic-augmented images needs fine-tuning.

For now, one immediate step you could take is to experiment with the mosaic augment parameter by either adjusting its probability or disabling it temporarily to see if that affects the accuracy of the bounding box placement. For example, to disable mosaic augmentation, you could adjust your dataset YAML as follows:

# In your dataset.yaml
mosaic: 0  # Set to 0 to disable mosaic augmentation

We'll delve into this issue and explore how we can enhance the model's handling of such cases. If you notice any other peculiar behaviors or have further insights, please keep sharing. Every bit of detailed feedback is a great asset in improving YOLOv8! 🚀

[farhanrw]

Thanks for the reply. This issue still persists with no mosaic augmentation, i.e. with mosaic: 0.

[glenn-jocher]

Hey there! Thanks for the update. 😊 If the issue persists even without mosaic augmentation, this gives us a clearer direction to investigate further. In the meantime, could you try tweaking other augmentation parameters (like perspective and translate) just to see if any specific augmentation is influencing the accuracy of OBB? For instance:

# Customizing augmentations
augment:
  perspective: 0.0  # Disable perspective changes
  translate: 0.0  # Disable translation

This could help isolate the problem while we dig deeper on our end. Thanks for your patience and for helping us pinpoint the issue!

[farhanrw]

Hi, has there been any update on this? @Burhan-Q @Laughing-q

[Yeah-l]

@glenn-jocher @farhanrw Guys the final augmented oriented bounding boxes are determined by the algorithm cv2.minAreaRect() that we uses in xyxyxyxy2xywhr function.

ultralytics/ultralytics/utils/ops.py

Line 539 in 5a82b51

(x, y), (w, h), angle = cv2.minAreaRect(pts)

For objects that are cut-off a lot by augmentations, current final boxes(shown above) might be the best the algorithm can do.
I've already figured a solution to alleviate the issue which showed better visual results in my tests on DOTAv1 dataset, that is to sample more(4 --> 100) coordinates(so that cv2.minAreaRect() could get xywhr from a more dense candidate) for each oriented bounding boxes to get better final results.

ultralytics/ultralytics/data/dataset.py

Line 219 in 5a82b51

segment_resamples = 100 if self.use_obb else 1000

@farhanrw From your samples the solution is not working very well on your dataset, could you upload a few samples here if you don't mind? so that we can try to figure a better solution.

@farhanrw @Laughing-q @glenn-jocher Thank you for your great work! However, I found that this situation would still occur if I set 100 interpolation points on bounding box. I think this reason is caused by the deletion of too many interpolation points when cropping, especially if the cropped bounding box ends up with two edges left on the original pic. Relying on interpolation points on the two borders can easily result in misalignment of the generated minimum external rectangle. I have given some pictures from dota datasets to show:

[glenn-jocher]

Thank you for your detailed insights and for sharing the visual examples from the DOTA dataset! Your observations about the interpolation points and the cropping effects on bounding boxes are very valuable.

It seems that the issue might indeed be related to how the bounding boxes are recalculated after cropping, especially when only two edges remain. This can lead to inaccuracies in the cv2.minAreaRect() function's output.

To further investigate and potentially resolve this, we could consider a few approaches:

1. Increase Interpolation Points: As you've already tried increasing the number of interpolation points, it might be beneficial to experiment with even higher values or different sampling strategies to see if it improves the bounding box accuracy.

2. Custom Post-Processing: Implement a custom post-processing step to refine the bounding boxes after augmentation. This could involve additional checks and adjustments to ensure the bounding boxes remain accurate.

3. Alternative Algorithms: Explore alternative algorithms or methods for calculating the minimum enclosing rectangle that might handle edge cases better.

If you have any additional insights or suggestions, please feel free to share them. Your contributions are greatly appreciated, and together we can work towards improving the OBB functionality for everyone. 🚀

Thank you for your patience and collaboration!