datasets/obb/

[giscus[bot]]

datasets/obb/

Dive deep into various oriented bounding box (OBB) dataset formats compatible with Ultralytics YOLO models. Grasp the nuances of using and converting datasets to this format.

https://docs.ultralytics.com/datasets/obb/

[z00bean]

The "YOLO OBB Format" subsection defines the format as:
class_index, x1, y1, x2, y2, x3, y3, x4, y4 (comma separated)

But later in the example the format is:
0 0.780811 0.743961 0.782371 0.74686 0.777691 0.752174 0.776131 0.749758

Can someone please confirm if both CSV and space separated formats are supported?

[pderrenger]

Hey there! 👋 Great question! Both CSV and space-separated formats are indeed supported for the YOLO OBB format. The key is consistency within your dataset. If you're using a .txt label file for an image, you can stick with the space-separated format as shown in the example:

0 0.780811 0.743961 0.782371 0.74686 0.777691 0.752174 0.776131 0.749758

This format should work seamlessly with your training process. Just ensure all your label files follow the same structure for the best results. Happy training! 🚀

[rbgreenway]

Do the obb's need to be right rectangles, i.e. angle between adjacent edges = 90 degrees? I'm assuming so, but I can't find where this is mentioned anywhere.
Thanks!!

[glenn-jocher]

Hey there! 😊

Thank you so much for the positive words! Happy to help.

For anyone diving into Oriented Bounding Box (OBB) datasets with Ultralytics YOLO models, you're on the right track! As mentioned in our docs, converting your dataset to the YOLO OBB format is key. Here's a quick example to get your custom dataset training-ready:

from ultralytics.data.converter import convert_dota_to_yolo_obb

# Convert DOTA dataset to YOLO OBB format
convert_dota_to_yolo_obb('path/to/DOTA')

And here's how you'd initiate training with this dataset:

from ultralytics import YOLO

# Train on your custom dataset
model = YOLO('yolov8n-obb.yaml')
results = model.train(data='your_dataset.yaml', epochs=100, imgsz=640)

Make sure your dataset annotations align with our “YOLO OBB format” for a smooth training process. Excited to see the amazing models you'll train! 🚀

If you have any more questions or need further clarification, feel free to ask. Happy coding!

[ma7555]

Hello, what happens if the xy points does not strictly adhere to the orthogonal geometry? I am labeling id cards and as you can tell, they are pretty much orthogonal but due to the camera angle and when I was labelling, i was just picking the 4 corners of the id. Am I good to go?

[glenn-jocher]

Hello,

If your labeled points do not strictly adhere to orthogonal geometry, the model can still handle them, but the accuracy might be affected. The YOLO OBB format expects the bounding boxes to be defined by their four corner points, which should ideally form right angles. However, slight deviations due to camera angles or labeling inaccuracies are generally manageable. It's important to ensure that the annotations are as precise as possible to maintain detection accuracy. If you encounter any issues, please check if they persist with the latest package versions.

[ma7555]

After testing, it is working pretty well.

[glenn-jocher]

Great to hear it's working well for you! If you encounter any issues or have further questions, feel free to ask. For more detailed information on OBB datasets and their formats, you can refer to our Oriented Bounding Box (OBB) Datasets Overview. This guide covers everything from dataset structure to format conversions, ensuring you have all the resources needed for effective model training.

[jadrian21]

Are there any OBB datasets for indoor furniture, like the Object models (Chair, Bed, Table, TV, etc...)

[pderrenger]

Hi there! 🙌

For indoor furniture datasets specifically designed with OBB (oriented bounding box) annotations, a direct reference within widely known datasets isn't readily available. However, DOTA is a popular dataset supporting OBB and primarily focuses on aerial images. To tailor it for indoor furniture, you might consider generating your own dataset or adapting existing ones into the YOLO OBB format for Ultralytics models.

Here's a snippet on how you could potentially convert a custom dataset to the YOLO OBB format:

from ultralytics.data.converter import convert_dota_to_yolo_obb

# Assuming you've annotated your indoor furniture dataset in a similar format to DOTA
convert_dota_to_yolo_obb('path/to/your_custom_dataset')

Remember, the key is to have your annotations in the correct format, as mentioned in the Oriented Bounding Box Datasets Overview. If you're starting from scratch, ensure your annotations follow the class_index, x1, y1, x2, y2, x3, y3, x4, y4 pattern, which is compatible with Ultralytics YOLO models.

Hope this points you in the right direction! If you end up creating a dataset for indoor furniture, we'd love to hear about your journey and learnings. Good luck! 🚀

[jadrian21]

Can you train you're model on just 3 classes? I'm primary interested in the "bed' and 'chair' and 'table', also what would be the minimum size of the dataset that you would recommend? Also, Is there a comprehensive guide on how to set up and train your own
data for a YOLOv8 model here or on another website you know of?

[pderrenger]

Hey there! 🌟 Absolutely, you can train a YOLOv8 model on just 3 classes like 'bed', 'chair', and 'table'. Regarding the dataset size, it's a bit tricky as the more data, the merrier (better model performance). However, starting with a few hundred images per class can be a good initial point, then gradually increase as needed.

For setting up and training your own data, our docs offer a great starting point, and though we don't have a dedicated "setting up" guide outside our docs, you can follow these steps for a quick start:

1. Prepare your dataset in the YOLO OBB format, as you're interested in OBB detection. Make sure your annotations follow the format:

class_index, x1, y1, x2, y2, x3, y3, x4, y4

2. Create a YAML file for your dataset specifying paths, classes, and class names.
3. Utilize the following code snippet to train:

from ultralytics import YOLO

model = YOLO('yolov8n-obb.yaml')  # Assuming you have an 'obb' model config
results = model.train(data='your_dataset.yaml', epochs=100, imgsz=640)

Or via CLI:

yolo detect train data=your_dataset.yaml model=yolov8n.pt epochs=100 imgsz=640

4. For converting other datasets to YOLO OBB format (if needed):

from ultralytics.data.converter import convert_dota_to_yolo_obb

convert_dota_to_yolo_obb('path/to/your_dataset')

Feel free to dive into our Oriented Bounding Box (OBB) Datasets Overview for more insights on dealing with OBB data. Happy training! 🚀

[nishantvm]

Hi, I am not able to wrap my head around the condition "l1 < l2" and "l1 > l2". I have cheque-shaped document that I have annotated, such that the top left corner of document is always x1, y1, and top right corner is x2, y2, and bottom right is x3, y3, and bottom left is x4, y4. This is regardless of orientation. But does the convention of height, width or point-based OBB change with orientation? Do we need to, at certain orientations, flip height and width in the training dataset? I believe this is a very crucial information and not having a single life of explanation above, apart from just the image.

[glenn-jocher]

@nishantvm hey there! 👋 It sounds like you're encountering some challenges with correctly orienting your bounding boxes during training, particularly with cheque-shaped documents. No worries, let's tackle this together!

For OBB (Oriented Bounding Boxes), it's essential to follow the YOLO OBB format accurately, where the annotation is based on the four corners of the object, regardless of its orientation. Given your annotation strategy (x1, y1, x2, y2, x3, y3, x4, y4), you've done it correctly by starting at the top left and moving clockwise. This method is consistent and should work well for any orientation.

Regarding the model predicting upside-down bounding boxes, it's often not about flipping height and width for certain orientations during training. Instead, it might be more about how the model is interpreting the angle or rotation of the objects. The YOLO OBB processes annotations in the xywhr format internally (center x, center y, width, height, rotation), converting your corner points into this format for processing.

If upside-down predictions occur, it may suggest that the model is having difficulty with the angle orientation understanding. This issue might not necessarily be fixed by adjusting the dataset but could be improved by:

1. Ensuring a wide variety of orientations is present in the training set to help the model learn the appropriate object orientation better.
2. Checking if augmentation techniques that include rotation are used, helping the model generalize better over different orientations.

In practice, the dataset should adequately represent the variation in orientation your application will encounter, without the need to manually flip dimensions based on orientation. If you're still facing issues, consider reviewing the distribution of orientations in your training data or possibly enhancing your dataset with more varied examples.

Hope this helps clear things up! If you have any more questions, feel free to ask. Happy training! 🚀

[nishantvm]

Glenn, thank you for your clarification. Can you please shed more light on images a) to f) above? particularly,
e) If L1 < L2, then
(x1, y1, x2, y2, x3, y3, x4, y4)

f) If L1 > L2, then
(x4, y4, x1, y1, x2, y2, x3, y3)

What does the above condition mean? Is there any paper for this that I can refer?

[glenn-jocher]

Hey there! Thanks for reaching out for more clarity on the L1 < L2 and L1 > L2 conditions related to oriented bounding boxes (OBB). 🌟

In the OBB context, think of L1 and L2 as two sides of the bounding box. These conditions help decide how to arrange the corner points (x1, y1, ..., x4, y4) based on the bounding box's orientation to ensure consistency in annotations. This can be particularly helpful when we're trying to standardize the way bounding boxes are defined, regardless of their rotation.

• For e) If L1 < L2, it suggests we're following a specific order (from top left corner clockwise) when one side (L1) is shorter than the other (L2).
• For f) If L1 > L2, this reorders the starting point when the previously shorter side (L1) becomes longer than the other side (L2), ensuring the annotation remains consistent with the bounding box's orientation.

This concept might not directly stem from a single paper but builds on common practices in handling oriented bounding boxes for object detection, particularly in aerial or satellite imagery where orientation varies widely.

While specific literature on this conditional formatting isn't directly listed, the overall methodology aligns with OBB handling in object detection tasks. For foundational understanding, checking out research and datasets in the aerial image domain, like DOTA, which is mentioned in our docs, can offer deeper insights into OBBs and their applications.

Hope this helps clear things up! Happy to assist further if you have more questions. Keep those great questions coming! 🚀

[Leo5050xvjf]

@glenn-jocher
Hi,
What do the terms e) and f) mean in the image? Do we need to change our labeling method based on the conditions of e) or f)? Or is it sufficient for the dataset to simply provide the four corners in either clockwise or counterclockwise order along with the category?
thanks.

[glenn-jocher]

Hey there! 👋

In terms of labeling and using the terms e) and f) referred to in the image, you don't need to change your labeling method as long as you're providing the four corners of the bounding boxes consistently. Whether that's clockwise or counterclockwise, what's crucial is maintaining that order throughout your dataset.

To clarify:

• e) L1 < L2: means to label your points starting from one corner and moving clockwise if one side of the box (L1) is shorter than the other side (L2).
• f) L1 > L2: instructs you to start from the adjacent corner if the first side (L1) is longer than the other side (L2).

This ensures that the data fed into the model remains consistent. YOLO processes this to maintain orientation understanding correctly during detection.

Keep your labeling consistent, and you should be good to go! Let me know if you need further assistance. Happy modeling! 🌟

[gabrielfaleiro]

Hi. First of all, great job documenting and training models! I had a great introduction with the YOLO models from your website.
I'm trying to create an OBB data set to train an obb trained yolov8 model. My intention is fine-tune the model to identify books in bookshelves. This way, I can extract text from each book separatedly.
However, the OBB YOLOv8 model has the following classes because they were trained with satellite images (DOTA):

# Classes for DOTA 1.0
names:
  0: plane
  1: ship
  2: storage tank
  3: baseball diamond
  4: tennis court
  5: basketball court
  6: ground track field
  7: harbor
  8: bridge
  9: large vehicle
  10: small vehicle
  11: helicopter
  12: roundabout
  13: soccer ball field
  14: swimming pool

How can I add a new label 'book' to the class IDs and get a succesful training?
I created this yaml file describing my new dataset of images.

path: datasets/books0 # dataset root dir
train: images/train # train images (relative to 'path')
val: images/val # val images (relative to 'path')

# Classes
names:
  0: plane
  1: ship
  2: storage tank
  3: baseball diamond
  4: tennis court
  5: basketball court
  6: ground track field
  7: harbor
  8: bridge
  9: large vehicle
  10: small vehicle
  11: helicopter
  12: roundabout
  13: soccer ball field
  14: swimming pool
  15: book

I defined the oriented boxes using the specified format:

15 0.549460 0.271452 0.567482 0.271452 0.567482 0.526935 0.549460 0.526935
15 0.608836 0.233848 0.628757 0.233583 0.630958 0.526785 0.611037 0.527050
15 0.631592 0.306224 0.643454 0.305908 0.646756 0.525706 0.634893 0.526022
15 0.646324 0.271602 0.704008 0.270065 0.707880 0.527873 0.650196 0.529410

And executed the following python code:

from ultralytics import YOLO
model = YOLO('yolov8x-obb.pt')
data = "datasets/books0/books0.yaml"
results = model.train(data=data, save=True, retina_masks=True)

But I got the following messages during the training which makes me think I'm doing something wrong.

WARNING ⚠️ No labels found in datasets\books0\labels\val.cache, training may not work correctly. See https://docs.ultralytics.com/datasets/detect for dataset formatting guidance.

What am I missing?
Thanks in advance.

[glenn-jocher]

Hey there! Thanks for sharing your positive experience with our YOLO models, and it's great to hear you're diving into creating an OBB dataset for such a cool project! ✨

From your description, it seems like you're on the right path by adding a 'book' label to your classes. If you're seeing a warning about no labels found, it's typically related to the dataset structure or the labeling format not being correctly recognized. Here are a few things to check:

1. Label Location: Ensure your labels for the training and validation datasets are placed in a labels folder parallel to your images folder within datasets/books0. The directory structure should look like this:

datasets/books0/
├── images/
│   ├── train/
│   └── val/
└── labels/
    ├── train/
    └── val/

2. Label Formatting: Double-check that your label text files match the expected YOLO OBB format. Each line should follow the format class_index x1 y1 x2 y2 x3 y3 x4 y4, with points normalized as mentioned.

If everything with the dataset looks correct and you're still encountering issues, try verifying your dataset with a smaller subset to ensure the format is being correctly applied.

Also, make sure the paths in your YAML file are correct relative to where you're running your training command from.

If after these checks you're still seeing the warning, there might be an issue with how the dataset is detected. Could you also verify if there's any content in your labels/val directory? Sometimes this warning can appear if the directory is empty or if the files are incorrectly named or formatted.

Feel free to share more insights if the issue persists. We're here to help! 🚀

[gabrielfaleiro]

Hi Glenn, thanks for your kind answer.
I'm starting with 5 images and apparently the warning was arising because some of the label files were empty. Once I created a few labes for each image, even though they are not complete yet, the python code didn't showed the warning.

[glenn-jocher]

Hey there! Great to hear that resolving the empty label files issue cleared up the warning for you. 👍 It's always wise to start with a few fully labeled images to ensure everything is working smoothly, then scale up as needed. Remember, each image file should have a corresponding label file in the correct format, even if some labels are initially incomplete.

If you continue to build out your dataset and run into any more questions or hiccups, feel free to drop a message. Happy training! 🚀

[masharib77]

Does yolov9c or yolov9e suppports obb ?

[pderrenger]

@masharib77 hi there!

Currently, the YOLOv9 models (c & e) do not support oriented bounding boxes (OBB). If you're specifically looking to work with OBB, you might want to consider the YOLOv8 models designed for OBB tasks. Here's an example of how you can train a YOLOv8 model on an OBB dataset:

from ultralytics import YOLO

# Create a new YOLOv8n-OBB model from scratch
model = YOLO('yolov8n-obb.yaml')

# Train the model on the DOTAv2 dataset
results = model.train(data='DOTAv1.yaml', epochs=100, imgsz=640)

This will help you get started with oriented bounding boxes using the supported YOLOv8 models. If you have further questions or need more assistance, feel free to ask! 🚀

[xinger1]

What is the representation of the rectangle box？Long side notation or opencv notation

[pderrenger]

@xinger1 hi there! 👋

In the YOLO OBB format, the bounding boxes are represented by the coordinates of their four corners. This format specifies each corner point normalized between 0 and 1. Here's a quick example of a bounding box for an object of class 0:

0 0.780811 0.743961 0.782371 0.74686 0.777691 0.752174 0.776131 0.749758

So, it's more aligned with the corner points notation rather than the OpenCV rectangle or long side notation (which typically uses x, y, width, height, and angle). Hope this clarifies things for you! If you have any more questions, feel free to ask. 😊

[bradley-skinner]

Hi there. I am using the xywhr2xyxyxyxy(rboxes) Ultralytics function to convert rboxes from (cx, cy, w, h, r). When testing with the same bbox globally oriented at [0,45,90,135,180,225,315], only the 0 and 180 orientations are correctly annotated onto the resulting image. So how does this function correctly orient bboxes say at 45 or 315 degrees, when the input rotation is clamped 0-90deg?

[pderrenger]

@bradley-skinner hello! It sounds like you're encountering an issue with the xywhr2xyxyxyxy function for rotations other than 0 and 180 degrees. The function is designed to handle rotations within the 0-90 degree range as it assumes symmetry for bounding box orientation. For rotations like 45 or 315 degrees, the bounding box should still be defined correctly if the rotation is interpreted as within this range.

If you're seeing discrepancies, it might be helpful to double-check the input format and ensure that the rotation angles are being input correctly as radians (if applicable) or adjusted to fit within the expected range. Here’s a quick example to ensure the rotation is applied correctly:

from ultralytics import xywhr2xyxyxyxy

# Example bbox with rotation at 45 degrees (converted to radians if needed)
bbox = [cx, cy, w, h, 45 * np.pi / 180]  # Convert degrees to radians
converted_bbox = xywhr2xyxyxyxy(bbox)

If issues persist, please provide a snippet of how you're applying the function along with sample inputs, and we can look deeper into it! 🛠️

[bradley-skinner]

Doh! Yep the conversion from degrees to radians was the issue!. However, the docstring for xywhr2xyxyxyxy(rboxes) and xyxyxyxy2xywhr(corners) does say " Convert batched Oriented Bounding Boxes (OBB) from [xy1, xy2, xy3, xy4] to [xywh, rotation]. Rotation values are expected in degrees from 0 to 90. My bad....I should have looked at the code and not the docstring and perhaps would have noticed that no degree->radians conversion was performed...Cheers!

[pderrenger]

Hey there! 🙌 Thanks for pointing out the confusion with the docstring. It's super helpful to get feedback like this to ensure our documentation is clear and accurate. We'll review the docstring for xywhr2xyxyxyxy(rboxes) and xyxyxyxy2xywhr(corners) to make sure it correctly reflects the expected input formats and conversions. Cheers for catching that and helping us improve! If you have any more insights or need further clarification, feel free to reach out. Happy coding! 😊

[bradley-skinner]

Glad to help. Keep up the excellent work!

[pderrenger]

Thanks for the kind words! 🌟 We're thrilled to hear you found the documentation helpful. If you have any more questions or need further assistance with OBB datasets or anything else, feel free to reach out. Happy coding! 😊

[iwanggp]

Do the boxes I annotate have to be rectangular boxes? Can they be only four points？Thank you

[pderrenger]

@iwanggp hi there!

Great question! Yes, you can annotate your bounding boxes using four points instead of rectangular boxes. Ultralytics YOLO models support Oriented Bounding Boxes (OBB), which are defined by their four corner points. This format is particularly useful for detecting objects that are not aligned with the image axes, such as those in aerial or satellite imagery.

Here's the format for YOLO OBB annotations:

class_index, x1, y1, x2, y2, x3, y3, x4, y4

Each coordinate (x, y) should be normalized between 0 and 1. Internally, YOLO processes these as xywhr (center point, width, height, rotation).

For example, an annotation might look like this:

0 0.780811 0.743961 0.782371 0.74686 0.777691 0.752174 0.776131 0.749758

To train a model using these OBB formats, you can follow this example:

from ultralytics import YOLO

# Create a new YOLOv8n-OBB model from scratch
model = YOLO("yolov8n-obb.yaml")

# Train the model on the DOTAv2 dataset
results = model.train(data="DOTAv1.yaml", epochs=100, imgsz=640)

For more details on OBB datasets and how to convert your annotations, please refer to our Oriented Bounding Box (OBB) Datasets Overview.

Feel free to reach out if you have any more questions! 😊

[iwanggp]

Thank you very much!

[pderrenger]

@iwanggp you're very welcome! 😊

If you have any further questions or run into issues, feel free to share more details. For any bug reports or issues, providing a minimum reproducible example can be incredibly helpful. You can find guidance on creating one here: Minimum Reproducible Example.

Additionally, please ensure you're using the latest versions of the Ultralytics packages to benefit from the latest fixes and features.

For more in-depth information on Oriented Bounding Box (OBB) datasets and how to work with them, you can refer to our Oriented Bounding Box (OBB) Datasets Overview.

Happy coding! 🚀

[CS-Guo]

I would like to model the results of the test and zoom in on the DOTAv1 TASK1 server for validation, but I have not been able to find a way to generate a submission format, can you help me please?

The requirements are as follows:
he aim of this task is to locate the ground object instances with an OBB.
Submission Format
You need to submit a zip file containing results for all test images for evaluation. The results are stored in n (n is the numer of categories) files, "Task1_plane.txt, Task1_storage-tank.txt, ...", each file contains all the detections for a specific category. Each file is in the following format:

imgname score x1 y1 x2 y2 x3 y3 x4 y4
imgname score x1 y1 x2 y2 x3 y3 x4 y4
...

[glenn-jocher]

@CS-Guo hi there!

Thank you for reaching out. To generate the submission format for the DOTAv1 TASK1 server, you can follow these steps to ensure your results are in the required format:

1. Run Inference: Use your trained YOLOv8n-OBB model to run predictions on your test images.
2. Format the Results: Convert the prediction results into the required submission format.

Here's a Python example to help you get started:

from ultralytics import YOLO

# Load your trained YOLOv8n-OBB model
model = YOLO("path/to/your/yolov8n-obb.pt")

# Run inference on your test images
results = model.predict(source="path/to/test/images", save_txt=True)

# Process the results to match the required submission format
import os

# Directory where the results are saved
results_dir = "runs/predict/exp/labels"

# Initialize a dictionary to store results for each category
category_results = {}

# Iterate over the result files
for file_name in os.listdir(results_dir):
    if file_name.endswith(".txt"):
        img_name = file_name.replace(".txt", "")
        with open(os.path.join(results_dir, file_name), "r") as f:
            for line in f:
                parts = line.strip().split()
                class_index = int(parts[0])
                score = float(parts[1])
                x1, y1, x2, y2, x3, y3, x4, y4 = map(float, parts[2:])
                
                # Create the result string
                result_str = f"{img_name} {score} {x1} {y1} {x2} {y2} {x3} {y3} {x4} {y4}\n"
                
                # Append the result to the corresponding category file
                category_file = f"Task1_{model.names[class_index]}.txt"
                if category_file not in category_results:
                    category_results[category_file] = []
                category_results[category_file].append(result_str)

# Save the results to the required format
output_dir = "submission"
os.makedirs(output_dir, exist_ok=True)
for category_file, lines in category_results.items():
    with open(os.path.join(output_dir, category_file), "w") as f:
        f.writelines(lines)

# Zip the submission folder
import shutil
shutil.make_archive("submission", 'zip', output_dir)

This script will generate the required Task1_<category>.txt files and zip them into a submission.zip file.

For more detailed guidance on working with OBB datasets and converting label formats, please refer to our Oriented Bounding Box (OBB) Datasets Overview.

If you encounter any issues or need further assistance, please provide a reproducible example of your problem. This will help us diagnose and resolve the issue more effectively. You can find more information on creating a minimum reproducible example here.

Lastly, ensure you are using the latest version of the Ultralytics packages to benefit from the latest features and bug fixes.

Best of luck with your submission! 🚀

[CS-Guo]

Thank you very much for your help! I have another question, I've been using SAHI (Slicing Aided Hyper Inference) recently and it seems to only support the normal horizontal box detection model, when using the OBB model I get an error, is there a solution for this now? Thank you very much!

[glenn-jocher]

Hi @CS-Guo,

Thank you for your kind words! 😊

Regarding your question about using SAHI (Slicing Aided Hyper Inference) with OBB models, it's true that SAHI primarily supports standard horizontal bounding box detection models. Unfortunately, this means that direct support for OBB models might not be available out-of-the-box with SAHI.

However, you can still work around this limitation by converting the OBB predictions to horizontal bounding boxes before using SAHI. Here's a basic approach to achieve this:

1. Convert OBB to Horizontal Bounding Boxes: Extract the minimum enclosing rectangle for each OBB.
2. Run SAHI on the Converted Bounding Boxes: Use these horizontal bounding boxes with SAHI for slicing and inference.

Here's a Python snippet to help you get started with converting OBB to horizontal bounding boxes:

import numpy as np
import cv2

def obb_to_hbb(obb):
    """
    Convert Oriented Bounding Box (OBB) to Horizontal Bounding Box (HBB).
    
    Args:
        obb (list): List of 8 coordinates representing the OBB [x1, y1, x2, y2, x3, y3, x4, y4].
    
    Returns:
        list: List of 4 coordinates representing the HBB [xmin, ymin, xmax, ymax].
    """
    points = np.array(obb).reshape(4, 2)
    rect = cv2.minAreaRect(points)
    box = cv2.boxPoints(rect)
    box = np.int0(box)
    xmin, ymin = np.min(box, axis=0)
    xmax, ymax = np.max(box, axis=0)
    return [xmin, ymin, xmax, ymax]

# Example usage
obb = [0.780811, 0.743961, 0.782371, 0.74686, 0.777691, 0.752174, 0.776131, 0.749758]
hbb = obb_to_hbb(obb)
print("Horizontal Bounding Box:", hbb)

Once you have the horizontal bounding boxes, you can proceed with SAHI as usual.

If you encounter any issues or need further assistance, please ensure you are using the latest versions of the packages and provide a reproducible example of your problem. This will help us diagnose and resolve the issue more effectively. You can find more information on creating a minimum reproducible example here.

I hope this helps! Let me know if you have any other questions.

[CS-Guo]

Hello, I recently found a problem, according to the code you gave to generate DOTAv1 Task1 format file, I found that the generated eight coordinates are in YOLO-OBB format (P0690__1024__0__53 0.315259 0.897871 0.397821 0.897231 0.396454 0.720936 0.313891 0.721576) instead of DOTA format (P2178 0.842247962952 193.0 442.0 267.0 444.0 266.0 522.0 192.0 520.0), may I ask if there is a way to solve this problem by converting yolo format to DOTA format? Thank you very much!

Translated with DeepL.com (free version)

[glenn-jocher]

Hi @CS-Guo,

Thank you for your detailed question! To convert the YOLO-OBB format to the DOTA format, you can follow these steps to ensure your results are in the required submission format for the DOTAv1 Task1 server.

Conversion Script

Here's a Python script to help you convert YOLO-OBB format to DOTA format:

import os

def yolo_obb_to_dota(yolo_obb_file, dota_file):
    with open(yolo_obb_file, 'r') as f:
        lines = f.readlines()

    with open(dota_file, 'w') as f:
        for line in lines:
            parts = line.strip().split()
            imgname = parts[0]
            score = float(parts[1])
            x1, y1, x2, y2, x3, y3, x4, y4 = map(float, parts[2:])
            f.write(f"{imgname} {score} {x1} {y1} {x2} {y2} {x3} {y3} {x4} {y4}\n")

# Example usage
yolo_obb_dir = "path/to/yolo_obb_results"
dota_dir = "path/to/dota_results"
os.makedirs(dota_dir, exist_ok=True)

for file_name in os.listdir(yolo_obb_dir):
    if file_name.endswith(".txt"):
        yolo_obb_file = os.path.join(yolo_obb_dir, file_name)
        dota_file = os.path.join(dota_dir, file_name)
        yolo_obb_to_dota(yolo_obb_file, dota_file)

# Zip the submission folder
import shutil
shutil.make_archive("submission", 'zip', dota_dir)

Steps:

1. Run Inference: Use your trained YOLOv8n-OBB model to run predictions on your test images.
2. Convert Results: Use the script above to convert the YOLO-OBB format results to the DOTA format.
3. Zip the Results: Ensure the results are zipped into a submission.zip file for submission.

Important Notes:

• Ensure your YOLO-OBB results are saved in the correct format before running the conversion script.
• Verify that the conversion script correctly formats the results as required by the DOTAv1 Task1 server.

For more detailed guidance on working with OBB datasets and converting label formats, please refer to our Oriented Bounding Box (OBB) Datasets Overview.

If you encounter any issues or need further assistance, please provide a reproducible example of your problem. This will help us diagnose and resolve the issue more effectively. You can find more information on creating a minimum reproducible example here.

Best of luck with your submission! 🚀

[DWendou]

For the box at the edge of the image, some box corners may not be on the image, how to deal with this? In addition, is there any data annotation tool recommended? thank you

[tconlon]

Unfortunately, not in all cases. For example in this screenshot, the objects need to be characterized by either 3, 5, or 6 exterior points.

(https://github.com/user-attachments/assets/50597c41-6046-42a0-a8b5-7b6021bab0f2)

[luo-ross]

Unfortunately, not in all cases. For example in this screenshot, the objects need to be characterized by either 3, 5, or 6 exterior points.

(https://github.com/user-attachments/assets/50597c41-6046-42a0-a8b5-7b6021bab0f2)

I think that we can only pass 4 coordinates. We only care about the center point, width, and height of the rectangle, and setting the rotation angle is the final position of the rectangle. The 5 points and 6 points you see are illusions. We only focus on the 4 vertices of the rectangle. At this point, we can use the xywhr method to calculate the positions of the 4 points through xywhr2xyxyxy. At this point, you will find that the coordinate points beyond the border are negative values

[luo-ross]

Unfortunately, not in all cases. For example in this screenshot, the objects need to be characterized by either 3, 5, or 6 exterior points.

(https://github.com/user-attachments/assets/50597c41-6046-42a0-a8b5-7b6021bab0f2)

I think that we can only pass 4 coordinates. We only care about the center point, width, and height of the rectangle, and setting the rotation angle is the final position of the rectangle. The 5 points and 6 points you see are illusions. We only focus on the 4 vertices of the rectangle. At this point, we can use the xywhr method to calculate the positions of the 4 points through xywhr2xyxyxy. At this point, you will find that the coordinate points beyond the border are negative values

[tconlon]

How would I convert these bounding boxes to xyxyxyxy for my labels then if all coordinates need to be clipped to [0,1]? It seems like at least 1 point will be missing in this conversion.

[pderrenger]

To handle bounding boxes with corners extending beyond the image boundaries, you can clip the coordinates to ensure they stay within the image dimensions. However, this might result in losing some parts of the object. For more accurate representation, you can use the xywhr format, which focuses on the center point, width, height, and rotation angle of the bounding box. This method ensures that the bounding box is accurately represented even if some corners fall outside the image. You can then convert these to the xyxyxyxy format using the xywhr2xyxyxyxy conversion function provided by Ultralytics. This approach maintains the integrity of the bounding box while adhering to the required format. For more details, refer to the Oriented Bounding Box (OBB) Datasets Overview.

[luo-ross]

My data annotation only has two situations: opening up and opening down. I tried using OBB and trained the data in the (id xyxyxy) format, and the predicted rotation direction was 1.570796 (90 °). I cannot know the true rotation direction of the target. How can I solve this problem? I have tried to randomly rotate all images by different angles and annotate them, but the training results still cannot correctly predict the rotation direction of vertically symmetric targets? I need to know the direction of the target's opening. Is YOLO OBB unable to solve this problem? Or where did I do it incorrectly? Is there anyone who can provide assistance?

[pderrenger]

@lsj13210 it sounds like you're encountering issues with the rotation prediction for vertically symmetric targets. YOLO OBB should be able to handle this, but the challenge might lie in the annotation or training process. Ensure your annotations are accurate and consistent. Also, try increasing the diversity of your training data by including more varied angles and scenarios. If the problem persists, verify that you're using the latest version of the Ultralytics package, as updates often include important fixes and improvements. For more detailed guidance, you can refer to the Ultralytics OBB documentation.

[luo-ross]

xyxyxyxy=ops.xywhr2xyxyxyxy(torch.tensor([200,200,170,100,1.57]))
data_array=xyxyxyxy.to(torch.int32).cpu().numpy()
x1y1=[data_array[0][0], data_array[0][1]]
x2y2=[data_array[1][0], data_array[1][1]]
x3y3=[data_array[2][0], data_array[2][1]]
x4y4=[data_array[3][0], data_array[3][1]]
xywhr=ops.xyxyxyxy2xywhr(torch.tensor([[x1y1, x2y2,x3y3, x4y4]])

here result r is not equal 1.57....why?

[luo-ross]

Thank you very much for your reply. I have upgraded the version to the latest version 8.2.58
code below
import ultralytics
from ultralytics import YOLO
import torch
import math
import cv2
import numpy as np

print(ultralytics.version)
#4 points
x1y1=[550.0,400.0]
x2y2=[450.0,400.0]
x3y3=[450.0,600.0]
x4y4=[550.0,600.0]

#clockwise
xywhr1=ops.xyxyxyxy2xywhr(torch.tensor([[x1y1,x2y2,x3y3,x4y4]]))
xywhr2=ops.xyxyxyxy2xywhr(torch.tensor([[x2y2,x3y3,x4y4,x1y1]]))
xywhr3=ops.xyxyxyxy2xywhr(torch.tensor([[x3y3,x4y4,x1y1,x2y2]]))
xywhr4=ops.xyxyxyxy2xywhr(torch.tensor([[x4y4,x1y1,x2y2,x3y3]]))

#anticlockwise
xywhr5=ops.xyxyxyxy2xywhr(torch.tensor([[x1y1,x4y4,x3y3,x2y2]]))
xywhr6=ops.xyxyxyxy2xywhr(torch.tensor([[x4y4,x3y3,x2y2,x1y1]]))
xywhr7=ops.xyxyxyxy2xywhr(torch.tensor([[x3y3,x2y2,x1y1,x4y4]]))
xywhr8=ops.xyxyxyxy2xywhr(torch.tensor([[x2y2,x1y1,x4y4,x3y3]]))

#result [tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708])]

According to the format class_index, x1, y1, x2, y2, x3, y3, x4, y4
nomatter how i did,the rotation angle is always the same ：90° rad 1.5708
i need rotation result show direction up ⬆ or down ⬇ vertical!

[glenn-jocher]

Thank you for updating to the latest version. The consistent rotation angle you're observing is likely due to the symmetrical nature of the bounding box coordinates you provided. The xywhr format calculates the rotation based on the relative positions of the corners, and in your case, the coordinates form a perfect rectangle, resulting in a consistent 90° rotation.

To achieve different rotation results, ensure that your input coordinates reflect the actual orientation of the objects. If you need further assistance with dataset preparation or conversion, please refer to the Ultralytics OBB documentation.

[luo-ross]

Hello, according to your suggestion, this OBB can only predict whether the target is rotating, but we cannot know the specific direction of the target's rotation? For example, this perfect rectangle. For a target, its self generation is determined by direction, just like a car. If it is vertically up or down, horizontally left, or horizontally right, the target forms a standard rectangle. At this point, it is impossible to predict which direction the front of the car is in, right? And what I need to solve now is, in this situation of vertical up or down, horizontal left or right, which side is the orientation of the front of the car? Can't it be completed using the OBB model?

[luo-ross]

I have found the cause of the problem. In YOLO OBB, when the rotation angle is greater than 90 or less than 0, xywhr needs to be changed to xyhwr to calculate xyxyxyxy.... I hope it will be helpful for newcomers to avoid this detour

[glenn-jocher]

Thank you for identifying the issue. Indeed, when dealing with rotation angles greater than 90 or less than 0, converting xywhr to xyhwr for calculating xyxyxyxy is necessary. This distinction helps ensure accurate orientation representation in the YOLO OBB format. Your insight will certainly be valuable for newcomers. For more detailed guidance on OBB datasets and conversions, you can refer to the Ultralytics OBB documentation.

[CS-Guo]

兄弟，你有没有在dota server 提交过，结果邮件点高不高

…

Sent from my iPhone

On Jul 17, 2024, at 19:31, lsj13210 ***@***.***> wrote:  xyxyxyxy=ops.xywhr2xyxyxyxy(torch.tensor([200,200,170,100,1.57])) data_array=xyxyxyxy.to(torch.int32).cpu().numpy() x1y1=[data_array[0][0], data_array[0][1]] x2y2=[data_array[1][0], data_array[1][1]] x3y3=[data_array[2][0], data_array[2][1]] x4y4=[data_array[3][0], data_array[3][1]] xywhr=ops.xyxyxyxy2xywhr(torch.tensor([[x1y1, x2y2,x3y3, x4y4]]) here result r is not equal 1.57....why? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[luo-ross]

I tested that OBB cannot handle vertical rotation prediction... According to the official method provided by xywhr2xyxyxyxy and then using xyxyxy2xywhr, results are inconsistent.. I directly tried to store the annotated results in xywhr format and then use the official xywhr2xyxyxy to generate the training dataset, but still couldn't predict the results correctly.

[glenn-jocher]

@lsj13210 it sounds like you're encountering issues with vertical rotation predictions using OBB in YOLO. The inconsistency you're seeing might be due to the conversion between xywhr and xyxyxyxy formats. Ensure you're using the latest version of the Ultralytics package, as updates often include bug fixes and improvements. If the issue persists, please provide more details or consider opening an issue on GitHub for further investigation. For more information on OBB datasets and conversions, you can refer to the Ultralytics OBB documentation.

[GuoQuanhao]

if l1 == l2, what should I do?

[glenn-jocher]

@GuoQuanhao if l1 == l2, you should ensure that your dataset annotations are correctly formatted according to the YOLO OBB format. This involves defining bounding boxes by their four corner points with coordinates normalized between 0 and 1. If you encounter issues, please verify that you are using the latest version of the Ultralytics package. For more detailed guidance, you can refer to the Oriented Bounding Box (OBB) Datasets Overview.

[luo-ross]

首先们要理解什么是OBB,OBB只是在目标检测的基础上加了一个旋转方向R，也就是说我们是没有办法去使用OBB来实现识别带方向的旋转。我们只能只能一个目标他有没有旋转，而旋转的方向也只有0-90°，这个你去查看官方源码也是这么解释的。所以我们只需要知道矩形框的中心，长和宽，还有旋转角度就可以，也就是所谓的xywhr,然后通过引用ultralytics.ops里的方法xywhr2xyxyxyxy就可以计算出矩形的四个点。然后把这四个点归一化，x除以宽度，y除以高度，然后按照官方说法id xyxyxyxy 一行一个矩形框准备训练数据，然后开始训练！剩下的就是等训练结果出来后，你调用YOLO.predict方法进行识别，然后结果obb里就有xywhr，这里的r就是旋转方向。另外需要注意的是在yolo里顺时针是正值，逆时针是负值，而0就是默认不带旋转的位置就是xywh轴对称的。所以不要去管什么长边短边，你标注的时候只需要提供矩形的四个定点，从哪个位置开始，顺时针逆时针连起来都无所谓，因为OBB不能识别目标的方向，而只能知道这个矩形有没有旋转！

[pderrenger]

@luo-ross thank you for your detailed explanation on Oriented Bounding Boxes (OBB) in YOLO models. To clarify, OBBs in Ultralytics YOLO are indeed represented by their four corner points, and the internal processing uses the xywhr format. This allows for accurate detection of rotated objects, particularly useful in aerial imagery. For converting DOTA dataset labels to the YOLO OBB format, you can use the convert_dota_to_yolo_obb function provided by Ultralytics. For more detailed information and examples, please refer to our documentation at https://docs.ultralytics.com/datasets/obb/.

[akvnn]

Hey, my dataset current format matches theta-based OBB. I understand that only point-based OBB is supported. Is there any reference of converting a theta based OBB to a point-based one (i.e., cx, cy, h, w, theta to the four corners)? I would appreciate your help in this.

[luo-ross]

from ultralytics import YOLO
import torch
import math
import ultralytics
from ultralytics.utils import ops

#your retangle center point x
x=500
#your retangle center point y
y=500
#your retangle width
w=200
#your retangle height
h=100
#your retangle rotate If there is no rotation angle, set it to 0
angle=45
#Convert the angle to radians
radians=math.radians(angle)
#from ultralytics.utils import ops, you can find function xywhr2xyxyxyxy and any other helpfull funtion you can use
xyxyxyxy=ops.xywhr2xyxyxyxy(torch.tensor([x,y,w,h,radians]))
#default is float ,if you want int data
#xyxyxyxy=xyxyxyxy.to(torch.int32)
#Now you can obtain the four vertices of any rectangle
x1y1=xyxyxyxy[0]
x2y2=xyxyxyxy[1]
x3y3=xyxyxyxy[2]
x4y4=xyxyxyxy[3]

[glenn-jocher]

@luo-ross thanks for your detailed example! To convert theta-based OBB (cx, cy, w, h, theta) to point-based OBB (four corners), you can use the xywhr2xyxyxyxy function from the ultralytics.utils.ops module. This function will help you transform the center coordinates, width, height, and rotation angle into the four corner points required by the YOLO OBB format. If you need further assistance, please refer to the Ultralytics OBB documentation for more details.

[SarhaneGhribi]

image 1/1 /content/datasets/Aerial-Solar-Panels-6/test/images/DJI_0753_MP4-28_jpg.rf.dfa764d53d312a5b3abf4262e53305ee.jpg: 640x640 12.5ms
Speed: 1.7ms preprocess, 12.5ms inference, 4.4ms postprocess per image at shape (1, 3, 640, 640)
ultralytics.engine.results.Results object with attributes:

boxes: None
keypoints: None
masks: None
names: {0: 'solar-panels'}
obb: ultralytics.engine.results.OBB object
orig_img: array([[[147, 159, 169],
[141, 154, 162],
[141, 150, 159],
...,
[ 68, 70, 78],
[ 68, 66, 72],
[ 40, 38, 44]],

   [[147, 159, 169],
    [140, 153, 161],
    [149, 158, 167],
    ...,
    [ 60,  62,  70],
    [ 61,  59,  65],
    [ 44,  42,  48]],

   [[146, 158, 168],
    [139, 152, 160],
    [161, 170, 179],
    ...,
    [ 62,  64,  72],
    [ 65,  63,  69],
    [ 38,  36,  42]],

   ...,

   [[112, 117, 120],
    [ 90,  95,  98],
    [103, 108, 111],
    ...,
    [ 34,  54,  49],
    [ 41,  61,  56],
    [ 17,  39,  34]],

   [[102, 107, 110],
    [ 96, 101, 104],
    [ 86,  91,  94],
    ...,
    [  9,  26,  22],
    [ 26,  43,  39],
    [ 17,  37,  32]],

   [[ 70,  75,  78],
    [ 77,  82,  85],
    [ 51,  56,  59],
    ...,
    [ 21,  36,  32],
    [ 37,  54,  50],
    [ 26,  43,  39]]], dtype=uint8)

orig_shape: (640, 640)
path: '/content/datasets/Aerial-Solar-Panels-6/test/images/DJI_0753_MP4-28_jpg.rf.dfa764d53d312a5b3abf4262e53305ee.jpg'
probs: None
save_dir: 'runs/obb/predict'
speed: {'preprocess': 1.7440319061279297, 'inference': 12.465476989746094, 'postprocess': 4.421472549438477}

this is the result i got , why does the boxes come out as none, i need to get the boxes directly from the prediction result not from the saved output file

[glenn-jocher]

@SarhaneGhribi it looks like the model didn't detect any bounding boxes in your image, which is why boxes is None. This could be due to several reasons, such as the confidence threshold being too high or the model not being trained adequately for your specific dataset. Please ensure your dataset is correctly formatted in the YOLO OBB format and that the model is trained properly. If the issue persists, try lowering the confidence threshold or retraining the model with more data. For more details on OBB datasets, you can refer to the Ultralytics OBB documentation.

[JasonSloan]

Im confused about the angle convertion during the training process.
During the training process, the code converts the xyxyxyxy format label to xywhr format with opencv's minAreaRect API, which the angle ranges from [0, pi/2) according to the docs in opencv. However, the angle ranges in model prediction which is [-pi/4, pi3/4) is different from the label. Why keep this inconsistence?

the function that convert label from xyxyxyxy2xywhr:

def xyxyxyxy2xywhr(x):
    """
    Convert batched Oriented Bounding Boxes (OBB) from [xy1, xy2, xy3, xy4] to [xywh, rotation]. Rotation values are
    returned in radians from 0 to pi/2.

    Args:
        x (numpy.ndarray | torch.Tensor): Input box corners [xy1, xy2, xy3, xy4] of shape (n, 8).

    Returns:
        (numpy.ndarray | torch.Tensor): Converted data in [cx, cy, w, h, rotation] format of shape (n, 5).
    """
    is_torch = isinstance(x, torch.Tensor)
    points = x.cpu().numpy() if is_torch else x
    points = points.reshape(len(x), -1, 2)
    rboxes = []
    for pts in points:
        # NOTE: Use cv2.minAreaRect to get accurate xywhr,
        # especially some objects are cut off by augmentations in dataloader.
        (cx, cy), (w, h), angle = cv2.minAreaRect(pts)
        rboxes.append([cx, cy, w, h, angle / 180 * np.pi])
    return torch.tensor(rboxes, device=x.device, dtype=x.dtype) if is_torch else np.asarray(rboxes)

the forward function of OBB head:

    def forward(self, x):
        """Concatenates and returns predicted bounding boxes and class probabilities."""
        bs = x[0].shape[0]  # batch size
        angle = torch.cat([self.cv4[i](x[i]).view(bs, self.ne, -1) for i in range(self.nl)], 2)  # OBB theta logits
        # NOTE: set `angle` as an attribute so that `decode_bboxes` could use it.
        angle = (angle.sigmoid() - 0.25) * math.pi  # [-pi/4, 3pi/4]
        # angle = angle.sigmoid() * math.pi / 2  # [0, pi/2]
        if not self.training:
            self.angle = angle
        x = Detect.forward(self, x)
        if self.training:
            return x, angle
        return torch.cat([x, angle], 1).transpose(-1,-2) if self.export else (torch.cat([x[0], angle], 1), (x[1], angle))

Thanks a lot!

[JasonSloan]

Sorry, there is another question i forgot to ask.
Futhermore, during the process of prediction, we should convert the range of the predict angle from [-pi/4, 3pi/4) to [0, pi/2) as the reverse of the training convertion.
However, i check the code below, and it seems to only confine the angle to [0, pi) rather than [0, pi/2) which not correspond to the comment.
Is the comment not correct or is my understanding wrong?
Thanks for your explaination!

def regularize_rboxes(rboxes):
    """
    Regularize rotated boxes in range [0, pi/2].

    Args:
        rboxes (torch.Tensor): Input boxes of shape(N, 5) in xywhr format.

    Returns:
        (torch.Tensor): The regularized boxes.
    """
    x, y, w, h, t = rboxes.unbind(dim=-1)
    # Swap edge and angle if h >= w
    w_ = torch.where(w > h, w, h)
    h_ = torch.where(w > h, h, w)
    t = torch.where(w > h, t, t + math.pi / 2) % math.pi     # This seems to only confine the angle to [0, pi) rather than [0, pi/2)
    return torch.stack([x, y, w_, h_, t], dim=-1)  # regularized boxes

[luo-ross]

Firstly, we need to understand what OBB means here. OBB: Oriented object detection goals a step further than object detection and introducing an extra angle to locate objects more accurately in an image. Therefore, we cannot use this to achieve directional object detection.

In addition
if we annotate the data, we only need to care about xywhr, because we can directly use the ops.xywhr2xyxyxy method to obtain the four points of the rectangle, which is also the safest method.

from ultralytics import YOLO
import torch
import math
import cv2
import numpy as np
#import utils you can get more functions here
from ultralytics.utils import ops
model = YOLO("best.pt") # pretrained YOLOv8n model
results = model.predict(r"imgname.png") # return a list of Results objects

Process results list

for result in results:
obb = result.obb # Oriented boxes object for OBB outputs
xywhr=obb.xywhr # center point, width, height, and rotation angle of the rectangle
xyxyxyxy=obb.xyxyxyxy #four points of the rectangle
rotation =obb.xywhr[:,4] #rotation angle of the rectangle
img=result.orig_img #Original image
for x in obb.xyxyxyxy:
data_array=x.cpu().numpy().astype(np.int32)
#Take these 4 points directly as a contour
cv2.drawContours(img, [data_array], -1, (255, 0, 0), 1,lineType=cv2.LINE_AA)
#We can also perform data conversion through this function
x1y1=[data_array[0][0], data_array[0][1]]
x2y2=[data_array[1][0], data_array[1][1]]
x3y3=[data_array[2][0], data_array[2][1]]
x4y4=[data_array[3][0], data_array[3][1]]
xywhr=ops.xyxyxyxy2xywhr(torch.tensor([[x1y1, x2y2,x3y3, x4y4]]).to(torch.float32))
#Obtain degree
degree=xywhr[0,4] * (180 / math.pi)
#Draw a cross
x=x1y1[0]
y=x1y1[1]
cv2.line(img, (x - 10, y), (x + 10, y), (0, 255, 0), 2)
cv2.line(img, (x, y - 10), (x, y + 10), (0, 255, 0), 2)
#Tag number
cv2.putText(img, "1", (data_array[0][0],data_array[0][1]), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 0, 255), 1, lineType=cv2.LINE_AA)
cv2.putText(img, "2", (data_array[1][0],data_array[1][1]), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 0, 255), 1, lineType=cv2.LINE_AA)
cv2.putText(img, "3", (data_array[2][0],data_array[2][1]), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 0, 255), 1, lineType=cv2.LINE_AA)
cv2.putText(img, "4", (data_array[3][0],data_array[3][1]), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 0, 255), 1, lineType=cv2.LINE_AA)
cv2.imshow('Rectangle', img)
cv2.waitKey(0)

[glenn-jocher]

@luo-ross oriented Bounding Boxes (OBB) in Ultralytics YOLO models are designed to improve detection accuracy by allowing bounding boxes to rotate and better fit objects. The regularize_rboxes function confines angles to [0, pi) to handle various orientations. This approach ensures flexibility in detecting objects at different angles. If you have further questions, feel free to ask!

[JasonSloan]

Thanks for your explaination!
I am still confused. The prediction of the model is xywhr, and what does the w mean?
Does it mean the longside of the rotated rectangle or something else?
May you give an example for illustration please?

[luo-ross]

@JasonSloan xywhr, where xy is the center coordinate of the rectangle, w is the width, h is the height, and r is the rotation angle, so we know if the rectangle has rotated. I think you may have fallen into a misconception that if you want to use OBB to achieve directional object detection, it should be like directional object detection in Halcon. If you want to achieve directional object detection, this OBB model may not be able to complete it, and you need to do more work. The most important thing to understand is that OBB in YOLO means: Oriented object detection goals a step further than object detection and introducing an extra angle to locate objects more accurately in an image It just adds an additional rotation angle on the basis of object detection. This rotation angle does not represent the direction of the target.

[Chen-chang-yu]

Hi, sirs. I already trained my custom dataset(80 picture), but the bounding box fited inaccurately for those at-an-angled object. On the other hand, those vertical/horizontal object fited the bounding box very well. I checked my labels (from xywhr to xyxyxyxyxy) are totally correct about corner location. I wanna know anyone has encountered this problem? I need help and suggestion to solve this. Thanks a lot

[glenn-jocher]

@Chen-chang-yu it sounds like the issue might be related to the dataset or model configuration. Ensure your dataset is correctly formatted in the YOLO OBB format. You might also want to experiment with different augmentation techniques or hyperparameters to improve the model's performance on angled objects. For more details, you can refer to the OBB documentation.

[Chen-chang-yu]

Appreciate for your kindly reply, and I checked my label is 0 0.5751953125 0.548828125 0.439453125 0.5732421875 0.412109375 0.4208984375 0.546875 0.3955078125 -- it's same with OBB format, so next step I will follow your suggestion to do augmentation and adjust hrperparameters to try. Thanks a lot.

[glenn-jocher]

You're on the right track. Ensure your augmentation techniques are diverse and consider adjusting hyperparameters like learning rate or batch size. This can help improve the model's performance on angled objects. Good luck!

[hodat2608]

Hi everyone! i have a question.
As we know, when i use labelimg obb to labeling images, it will export xywhr coordinates, example :
0 88.000000 101.000000 141.785406 14.314282 89.065522
0 477.548407 102.450004 140.874897 13.174511 -89.889658
0 218.000000 102.500000 140.785539 14.297973 89.065522

but if i use this format for training it gives error, can not train, i think i need to convert this xywhr format to xyxyxyxy format.
So I need to consult everyone, how to convert this format. thanks
*note: we need to pay attention to the angle during labeling, because when we use label img obb, the angle will be output as negative and positive, which means if it is less than 90 degrees it is negative, if it is greater than 90 degrees it is positive. However, in YOLOv8 it will not be shown like that, it will output the result always positive,
**for example :
label img obb : -89 degrees < 90 degrees < 89 degrees
yolov8 : 89 degrees < 90 degrees < 91 degrees
i use this source : https://github.com/heshameraqi/labelImg_OBB

[luo-ross]

For appropriation, here is ready-made code, hoping it will be helpful to you

from ultralytics import YOLO
import time
import torch
import math
import cv2
import numpy as np
import ultralytics

from ultralytics.utils import ops

img=cv2.imread(r"yourfilename.png")

#4 points
x1y1=[550.0,400.0]
x2y2=[450.0,400.0]
x3y3=[450.0,600.0]
x4y4=[550.0,600.0]

Example bbox with rotation at 45 degrees (converted to radians if needed)

r1=0 * np.pi / 180
r2=-45 * np.pi / 180
bbox = [500, 500, 200, 100, r1] # Convert degrees to radians
xyxyxyxy =ops. xywhr2xyxyxyxy(torch.tensor(bbox))
xywhr=ops.xyxyxyxy2xywhr(xyxyxyxy.reshape(1,-1,2))

rotate=xywhr[:,4]*180/np.pi
#clockwise
xywhr1=ops.xyxyxyxy2xywhr(torch.tensor([[x1y1,x2y2,x3y3,x4y4]]))
xywhr2=ops.xyxyxyxy2xywhr(torch.tensor([[x2y2,x3y3,x4y4,x1y1]]))
xywhr3=ops.xyxyxyxy2xywhr(torch.tensor([[x3y3,x4y4,x1y1,x2y2]]))
xywhr4=ops.xyxyxyxy2xywhr(torch.tensor([[x4y4,x1y1,x2y2,x3y3]]))

#anticlockwise
xywhr5=ops.xyxyxyxy2xywhr(torch.tensor([[x1y1,x4y4,x3y3,x2y2]]))
xywhr6=ops.xyxyxyxy2xywhr(torch.tensor([[x4y4,x3y3,x2y2,x1y1]]))
xywhr7=ops.xyxyxyxy2xywhr(torch.tensor([[x3y3,x2y2,x1y1,x4y4]]))
xywhr8=ops.xyxyxyxy2xywhr(torch.tensor([[x2y2,x1y1,x4y4,x3y3]]))

r=[xywhr1[:,4],xywhr2[:,4],xywhr3[:,4],xywhr4[:,4],xywhr5[:,4],xywhr6[:,4],xywhr7[:,4],xywhr8[:,4]]

#xyxyxyxy=ops.xywhr2xyxyxyxy(torch.tensor([161,152,100,170,math.radians(0)]))

data_array=xyxyxyxy.to(torch.int32).cpu().numpy()
cv2.drawContours(img, [data_array], -1, (255, 0, 0), 2)

x=data_array[0][0]
y=data_array[0][1]
x1y1=[data_array[0][0], data_array[0][1]]
x2y2=[data_array[1][0], data_array[1][1]]
x3y3=[data_array[2][0], data_array[2][1]]
x4y4=[data_array[3][0], data_array[3][1]]

xywhr=ops.xyxyxyxy2xywhr(torch.tensor([[x1y1, x2y2,x3y3, x4y4]]).to(torch.float32))

cv2.line(img, (x - 10, y), (x + 10, y), (0, 255, 0), 2)
cv2.line(img, (x, y - 10), (x, y + 10), (0, 255, 0), 2)

cv2.putText(img, "1", (data_array[0][0],data_array[0][1]), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 0, 255), 1, lineType=cv2.LINE_AA)
cv2.putText(img, "2", (data_array[1][0],data_array[1][1]), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 0, 255), 1, lineType=cv2.LINE_AA)
cv2.putText(img, "3", (data_array[2][0],data_array[2][1]), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 0, 255), 1, lineType=cv2.LINE_AA)
cv2.putText(img, "4", (data_array[3][0],data_array[3][1]), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 0, 255), 1, lineType=cv2.LINE_AA)
cv2.imshow('Rectangle', img)
cv2.waitKey(0)

#[tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708]), tensor([1.5708])]

sd2=ops.xywhr2xyxyxyxy(torch.tensor([500,500,200,100,math.radians(-90)]))

sd3=ops.xywhr2xyxyxyxy(torch.tensor([500,500,200,100,math.radians(180)]))
sd4=ops.xywhr2xyxyxyxy(torch.tensor([500,500,200,100,math.radians(270)]))
sd5=ops.xywhr2xyxyxyxy(torch.tensor([500,500,200,100,math.radians(360)]))

sd6=ops.xywhr2xyxyxyxy(torch.tensor([500,500,200,100,math.radians(45)]))

radians=math.radians(-90)

test1=ops.xyxyxyxy2xywhr(torch.tensor([[100, 100, 100, 461.999104, 911.0016, 272.999424, 1066.99776, 527.0016]]))
test2=ops.xyxyxyxy2xywhr(torch.tensor([[ 640.999424, 461.999104, 911.0016, 272.999424, 1066.99776, 527.0016,797.999104, 706.999296]]))
test3=ops.xyxyxyxy2xywhr(torch.tensor([[ 461.999104, 911.0016, 272.999424, 1066.99776, 527.0016,797.999104, 706.999296, 640.999424]]))
test4=ops.xyxyxyxy2xywhr(torch.tensor([[706.999296, 640.999424,461.999104, 911.0016, 272.999424, 1066.99776, 527.0016,797.999104 ]]))

[hodat2608]

I have another question? I want to train with higher imgsz, so what size is best for practice? 832 or 1280 ?

[luo-ross]

@hodat2608 Unless your application scenario is microscopic, such as those captured under a microscope, requiring recognition of cells or bacteria, and requires precision at the pixel level. So when you train, you need to ensure the size of the image. For example, if a 2448 * 2048 size image is scaled to 640 * 640, it may not be able to recognize the target well. So you can use larger training sizes, such as twice, three times, or four times 640, or ensure that the size is a multiple of 2 for better results. Of course, the larger the size, the lower the efficiency. You need to use GPU for training and prediction.

[glenn-jocher]

The best image size depends on your specific use case and hardware capabilities. Generally, larger sizes like 1280 can improve accuracy but require more computational resources. If you're limited by hardware, 832 might be a more practical choice.

[DeekshithaDPrakash]

Hi everyone! i have a question. As we know, when i use labelimg obb to labeling images, it will export xywhr coordinates, example : 0 88.000000 101.000000 141.785406 14.314282 89.065522 0 477.548407 102.450004 140.874897 13.174511 -89.889658 0 218.000000 102.500000 140.785539 14.297973 89.065522

but if i use this format for training it gives error, can not train, i think i need to convert this xywhr format to xyxyxyxy format. So I need to consult everyone, how to convert this format. thanks *note: we need to pay attention to the angle during labeling, because when we use label img obb, the angle will be output as negative and positive, which means if it is less than 90 degrees it is negative, if it is greater than 90 degrees it is positive. However, in YOLOv8 it will not be shown like that, it will output the result always positive, **for example : label img obb : -89 degrees < 90 degrees < 89 degrees yolov8 : 89 degrees < 90 degrees < 91 degrees i use this source : https://github.com/heshameraqi/labelImg_OBB

@hodat2608 Did you solve this issue and train yolo model for OBB ?
It would be of great help if you could share relevant materials

[CharlesNord]

According to the regularize_rboxes in ultralytics/utils/ops.py , it seems the image (e), (f) in the tutorial above is not correct, the code compares the width and the height of the predicted bbox to adjust the predicted OBB parameters, not the length of l1 and l2 in the images (e), (f).

[glenn-jocher]

@CharlesNord thank you for pointing this out. The regularize_rboxes function indeed uses width and height for adjustments. If you have further questions, feel free to ask!

[AntDX316]

How do we easily create Mask OBB?

Also, can it be possible to ensure a bearing/direction for the front is baked into the dataset too?

If it doesn't exist yet, can you guys ensure this is reliable on a new update?

[glenn-jocher]

@AntDX316 thank you for your question! To create Mask OBB, you'll need to ensure your dataset annotations are converted to the YOLO OBB format, which uses four corner points for bounding boxes. You can integrate additional metadata like bearing/direction by including it in your dataset's custom annotation structure, though this feature is not natively supported yet. For feature requests or updates, please consider submitting a formal issue or suggestion on the repository for the team to review. For more details on OBB datasets, visit OBB Datasets Overview.

[rihablahouar]

Issue with Incorrect Predictions from Quantized YOLOv8m-obb Model (TFLite) in TensorFlow Framework

I have exported my YOLOv8m-obb model to TFLite format with INT8 quantization enabled, using an image size of 640x640 and a data.yaml for my dataset. When I use the quantized model for inference with the Ultralytics framework (Oriented Bounding Boxes), the predictions are correct. However, when I use the same model in the TensorFlow framework, I encounter several issues with the output:

Confidence scores are greater than 1, which is incorrect.
The class_id is either -1 or 0, but it should be 0 or 1 since I have only two classes.
The x and y coordinates have values of -1, which is wrong.

I suspect there might be an issue with how the quantization parameters (scale and zero-point) are being applied in TensorFlow, or possibly with the way I'm handling the model's output or the way I exported the model. I would appreciate guidance on how to correctly handle the quantized model in TensorFlow and resolve the issues with incorrect predictions.

[glenn-jocher]

@rihablahouar the issue likely arises due to differences in how TensorFlow interprets or handles the quantized TFLite model's outputs. Ensure that the post-processing operations (like decoding bounding boxes, confidence scores, and class indices) align with the model's export format and scale/zero-point quantization parameters. Additionally, verify the TensorFlow inference pipeline against the Ultralytics implementation for any discrepancies. For further debugging, you may find it useful to test the unquantized TFLite model in TensorFlow to isolate the quantization's impact.