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! 👋

Yes, in the YOLOv8 OBB context, the rectangles do align to the right-angled expectation. The YOLO OBB format primarily works with four corner points (x1, y1, x2, y2, x3, y3, x4, y4). While not explicitly stated, the model's internal processing leans on this geometric property for calculating the oriented bounding boxes.

When defining an OBB, each corner point follows the next in a clockwise or counter-clockwise manner, ensuring the angles between joined edges adhere to a 90-degree framework by construction. This setup facilitates efficient loss calculation and model predictions under the premise of right-angled rectangles.

Here's a quick glimpse at how you might denote an OBB in a label file:

0 0.780811 0.743961 0.782371 0.74686 0.777691 0.752174 0.776131 0.749758

This representation indirectly ensures that adjacent edges form right angles, aligning with your assumption. It's a fundamental geometric characteristic inherent in our OBB handling methodology. Hope that answers your question! If there’s anything more you’d like to know, feel free to ask. 😊

[rbgreenway]

Excellent response! Thank you, Glenn.

[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!

[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

[pderrenger]

@DWendou hi there!

For handling bounding boxes at the edge of the image where some corners might fall outside the image boundaries, you can clip the coordinates to ensure they stay within the image dimensions. This can be done programmatically during preprocessing or data augmentation steps. Here's a simple example in Python:

import numpy as np

def clip_box(box, img_shape):
    """
    Clips the bounding box coordinates to be within the image boundaries.
    Args:
        box (list): List of coordinates [x1, y1, x2, y2, x3, y3, x4, y4].
        img_shape (tuple): Shape of the image (height, width).
    Returns:
        list: Clipped bounding box coordinates.
    """
    h, w = img_shape
    box = np.array(box).reshape(-1, 2)
    box[:, 0] = np.clip(box[:, 0], 0, w)
    box[:, 1] = np.clip(box[:, 1], 0, h)
    return box.flatten().tolist()

# Example usage
box = [0.9, 0.9, 1.1, 0.9, 1.1, 1.1, 0.9, 1.1]
img_shape = (640, 640)
clipped_box = clip_box(box, img_shape)
print(clipped_box)

Regarding data annotation tools, there are several popular ones you can use for creating OBB annotations:

1. LabelImg: A graphical image annotation tool that supports both Pascal VOC and YOLO formats. It can be extended to support OBB annotations with some customization.
2. LabelMe: Another graphical annotation tool that supports polygonal annotations, which can be converted to OBB format.
3. Roboflow: An online platform that supports various annotation formats and can help with converting and managing datasets.

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

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

[DWendou]

If you do this, you can't completely label the whole object, and when you use the annotation tool, how do I label the corners outside the image?

[pderrenger]

Hi there!

When dealing with bounding boxes at the edge of an image where some corners might fall outside the image boundaries, it's essential to clip these coordinates to ensure they stay within the image dimensions. This can be done programmatically during preprocessing. Here's a quick example in Python:

import numpy as np

def clip_box(box, img_shape):
    """
    Clips the bounding box coordinates to be within the image boundaries.
    Args:
        box (list): List of coordinates [x1, y1, x2, y2, x3, y3, x4, y4].
        img_shape (tuple): Shape of the image (height, width).
    Returns:
        list: Clipped bounding box coordinates.
    """
    h, w = img_shape
    box = np.array(box).reshape(-1, 2)
    box[:, 0] = np.clip(box[:, 0], 0, w)
    box[:, 1] = np.clip(box[:, 1], 0, h)
    return box.flatten().tolist()

# Example usage
box = [0.9, 0.9, 1.1, 0.9, 1.1, 1.1, 0.9, 1.1]
img_shape = (640, 640)
clipped_box = clip_box(box, img_shape)
print(clipped_box)

For annotation tools, here are a few recommendations that support OBB annotations:

1. LabelImg: A graphical image annotation tool that supports both Pascal VOC and YOLO formats. It can be extended to support OBB annotations with some customization.
2. LabelMe: Another graphical annotation tool that supports polygonal annotations, which can be converted to OBB format.
3. Roboflow: An online platform that supports various annotation formats and can help with converting and managing datasets.

For more detailed information on OBB datasets and how to work with them, please refer to our Oriented Bounding Box (OBB) Datasets Overview.

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