Oriented Bounding Box Detection with Ultralytics YOLO

Model ensembling with YOLOv8-obb models involves combining the predictions from multiple trained models to improve the accuracy of your oriented objects detection. Currently, direct support for model ensembling within Ultralytics YOLO isn't provided out-of-the-box. However, you can manually implement ensembling by running predictions with each model separately and then combining these predictions.

One common approach is to average the bounding box coordinates and confidence scores of the same object detected by multiple models. Ensure to consider the rotating angle parameter unique to OBB models in your ensembling logic. Here's a basic conceptual example to get you started:

from ultralytics import YOLO

models = [
    YOLO('path/to/first_obb_model.pt'),
    YOLO('path/to/second_obb_model.pt'),
    # Add more models as needed
]

# Assuming you have a method to read your images/videos
image = 'path/to/image.jpg'

# List to store results from all models
all_preds = []

for model in models:
    results = model(image)
    all_preds.append(results[0].obb)  # Extracting OBB predictions (xywhr, conf, cls)

# Assuming you have a method `combine_predictions(all_preds)`
# that combines predictions from all models
final_predictions = combine_predictions(all_preds)

# Process `final_predictions`...

This example loads each model, runs predictions on the same image, and stores the results. You'd then need to implement combine_predictions(all_preds) to handle the logic for combining these predictions based on criteria like IoU, confidence scores, etc., taking into account the angle for rotated bounding boxes.

Remember, ensembling may increase inference time due to processing with multiple models. Always weigh the benefits of improved accuracy against potential increases in computational cost. Happy coding! 😊

@windzu thank you for sharing the code example. For more details on using YOLOv8 Oriented Bounding Boxes, please refer to our documentation on training, validation, and exporting models. If you have further questions, feel free to ask here.

@krialm In the case of OBB, you can get bounding box data, using the mentioned code below.

model = YOLO("yolov8n-obb.pt")
results = model.predict(im0)
pred_boxes = results[0].obb

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

Thanks and Regards Ultralytics Team!

Is there a way for me to train OBB models from scratch let's say the P2 or RTDETR models which are not available pre-trained?

@kedardg absolutely, you can train OBB models like P2 or RTDETR from scratch even if they're not available pre-trained. You'd start by creating a new model from a YAML file, which defines the model architecture. Here's a quick example of how you might do it:

yolo obb train data=your_dataset.yaml model=your_model.yaml epochs=100 imgsz=640

Just replace your_dataset.yaml with your dataset configuration file and your_model.yaml with your model configuration file. Make sure your dataset is properly formatted for OBB tasks. Happy training! 😊🚀

model = YOLO("yolov8n-obb.pt") results = model.predict(im0) pred_boxes = results[0].obb

i did this but i want to draw bounding boxes on the test image and return it. how to do that?

my function is:

def count_detection(image): if image is not None: # Load the YOLO model model = YOLO('bestobbv8s.pt')

    # Check the shape of the input image
    print("Input image shape:", image.shape)

    # Use the model to predict the wheat spikes in image
    results = model(image, save=True)

    # Count 
    count = sum(len(result) for result in results)
    print("count", count)

    # Draw bounding boxes for detected wheat heads
    for result in results:
        boxes = result.obb
        #here?
        
    return image

@RumaisaIlyas hey there! 😊 To draw bounding boxes on your test image and return it, you can use the plot() method available in the Results object. Here's how you can modify your function:

def count_detection(image):
    if image is not None:
        # Load the YOLO model
        model = YOLO('bestobbv8s.pt')

        # Check the shape of the input image
        print("Input image shape:", image.shape)

        # Use the model to predict
        results = model.predict(image)

        # Draw bounding boxes and return the annotated image
        annotated_image = results[0].plot()

        # Count detections
        count = len(results[0].obb)
        print("count", count)

        return annotated_image

In this updated function, after making predictions with model.predict(image), we use results[0].plot() to draw bounding boxes on the image. This method returns the annotated image, which we then return from the function. This should give you the visual feedback you're looking for! 🚀

Let me know if you need further assistance!

thankyou so much for your assistance. i am facing a problem that my runs folder is not created after i run the code provided. why is that? what should i do in code so that i get the runs folder with my predicted image

Hey there! 😊 It sounds like you're doing everything right, but if the runs folder isn't being created, it might be due to a small oversight. Here's a quick checklist:

1. Ensure you're using the latest version of the Ultralytics YOLO library. Sometimes, updates fix these kinds of issues.
2. Double-check your command and make sure it's complete. For predictions, it should look something like this:

from ultralytics import YOLO

# Load your model
model = YOLO('bestobbv8s.pt')

# Run prediction
# save=True writes the annotated image to the 'runs' folder
results = model.predict('path/to/your/image.jpg', save=True)

1. If you're still not seeing the runs folder, try specifying the output directory explicitly in your code:

results = model.predict('path/to/your/image.jpg', save=True, project='runs/detect')  # Adjust the path as needed

1. Lastly, ensure you have the necessary write permissions in your working directory. Sometimes, permission issues can prevent the creation of new folders.

If you've checked all these and the issue persists, it might be helpful to share more details about your environment (like your operating system) or any error messages you're seeing. That way, the community can offer more targeted advice. 🚀

Hope this helps, and happy detecting!

I also face the same problem. I tried using the code provided but it still says NoneType

ncnn_model = YOLO("./my_ncnn_model", task='detect') results = ncnn_model.predict(image_path)

if results[0] is not None: # Ensure results is not None obb_boxes = results[0].obb # For OBB models print(f"OBB Box: {obb_boxes}") else: print("No detections.")

This is what I get

Speed: 4.1ms preprocess, 93.1ms inference, 1.2ms postprocess per image at shape (1, 3, 640, 640) OBB Box: None

Any help?

the radian range is [-π/4, 3π/4), i.e. [-45°, 135°), not [0°, 90°). that docs note was inaccurate and is fixed in #24534.

ground-truth angles are normalized in xyxyxyxy2xywhr (ultralytics/utils/ops.py) by two loops, while theta >= 3*pi/4: theta -= pi and while theta < -pi/4: theta += pi, with w swapped to the longer side. sweeping a rectangle through physical 0->180°:

  0° -> 0.0000       45° -> 0.7854 (π/4)     90° -> 1.5708 (π/2)
120° -> 2.0944      135° -> -0.7854 (-π/4)  165° -> -0.2618

so the span is exactly π wide, half-open at 3π/4.

the heads match this:

• OBB (yolov8/yolo11): angle = (sigmoid(raw) - 0.25) * π, hard-bounded to [-π/4, 3π/4].
• OBB26 (yolo26): raw output, no sigmoid, trained on targets already in [-π/4, 3π/4).

[0, π/2) is the regularized DOTA-style form produced by regularize_rboxes in ops.py. that function is defined but has no callers anywhere in ultralytics/, so it is not applied at training or inference. predicted boxes reach you unregularized: result.obb.xywhr returns the angle in [-π/4, 3π/4) (verified by feeding angles like -0.70 and 2.30 through the predict path and reading them back unchanged).

one consequence, which is what the original note was really about: an OBB and its 180° rotation encode to the same xywhr, so rotation is defined only modulo 180° and the box has no direction. θ and θ+180° are indistinguishable, so you cannot recover a fixed corner ordering from the predicted angle.

Here, “multiscale” means evaluating the same trained model on multiple resized/split versions of each DOTA image tile, then merging those detections back into the original image for final submission; in Ultralytics this is tied to the DOTA split pipeline with scales like rates=[0.5, 1.0, 1.5] in the DOTA dataset guide and the merged-result export in OBBValidator.eval_json(), so it is usually multi-scale test-time inference with one model rather than separately training 512 and 1024 models.

it is one model, trained once. there is no separate 512 and 1024 model, and no separate training runs per scale. the "multiscale" lives entirely in the dota tiling step, not inside yolo val.

where it comes from. dota images are huge (800x800 up to ~20000x20000), so they are cut into overlapping tiles before training/val using split_trainval / split_test from ultralytics/data/split_dota.py. the multiscale variant passes rates=[0.5, 1.0, 1.5] (this is exactly what the dota dataset guide shows). for each rate r the code uses crop_size / r and gap / r, so with the defaults crop_size=1024, gap=200 you get tiles of:

rate 0.5 -> 2048 px tiles (gap 400)
rate 1.0 -> 1024 px tiles (gap 200)
rate 1.5 ->  682 px tiles (gap 133)

every original image is therefore cut into overlapping windows at all three crop sizes. each window is later resized to imgsz at inference, so the same content is effectively seen at three resolutions. concretely, a single 4000x4000 image produces ~98 tiles spread across those three sizes.

training. the model is trained once on the multiscale-split trainval tiles (same rates=[0.5, 1.0, 1.5]). it is not "trained at 512 then at 1024" as separate models.

test / how the final number is obtained. yolo val obb data=DOTAv1.yaml split=test runs that single model over every test tile. each tile filename encodes the source image id and crop offset (name__cropsize__xstart___ystart). OBBValidator.eval_json() parses that, shifts each tile's rotated boxes back into the original full-image coordinates, concatenates detections from all tiles and all scales, then runs a rotated probiou NMS (fast_nms, iou 0.3) to remove the overlap introduced by tiling. the merged per-image results are written as dota Task1_*.txt, which is what you submit to the dota evaluation server.

one practical caveat. yolo val ... split=test does not create the multiscale tiles for you. you have to run split_test(rates=[0.5, 1.0, 1.5]) first (and split_trainval with the same rates for training). running val on the raw full dota images is single-scale and will not reproduce the mAPtest number in the table.

so in short: multiscale = offline multi-scale tiling + per-tile single-scale inference + merge-back-and-NMS, all with one model. it is test-time multi-scale through the tiling, not test-time augmentation inside val.

That warning is expected for OBB models: CoreML nms=True is only supported for axis-aligned Detect heads, so export your *-obb model without NMS and do confidence/IoU (rotated NMS) post-processing on the app side (export success ✅ means you’re fine). See the Ultralytics YOLO OBB task docs for the OBB output formats.

yolo export model=best.pt format=coreml