zh/tasks/obb/

[giscus[bot]]

zh/tasks/obb/

了解如何通过Ultralytics YOLO 使用面向对象检测模型。有关训练、验证、图像预测和模型导出的说明。

https://docs.ultralytics.com/zh/tasks/obb/

[Morrison-Zhao]

Hello, I am currently trying to use yolov8_obb for vehicle recognition and trajectory tracking. However, whether I use the predict method or directly input the model (jpg) into the image, the boxes in the result obtained are None. Is there a good solution that can help me solve the problem? Thank you very much. I just hope to draw the motion trajectories of these vehicles in the output video. Here is my code:
break

[pderrenger]

@ZzMLvzZ-792998470 hello! Thank you for your kind words and for sharing your journey with YOLOv8 OBB for vehicle recognition and tracking. It's great to hear about your progress and your initiative to draw motion trajectories. Let's address your concerns:

1. Accessing Boxes for Trajectory Drawing: You're on the right track! For drawing trajectories, you indeed need to access the bounding boxes (or oriented bounding boxes, OBB, in your case) from the tracking results. Since you're using yolov8n-obb.pt, the results should contain the OBB information you need.

2. Understanding persist and stream Parameters:

   • persist=True helps in maintaining the identity of objects across frames, which is crucial for tracking their motion.
   • stream=True is used for processing video streams efficiently, especially for long videos or live feeds, by optimizing memory usage.

3. Drawing Trajectories: Your idea of drawing a pixel at the center of the recognition box and retaining it for a few frames is a good starting point. You can store the center points of each vehicle's bounding box and draw lines connecting these points across frames to visualize the trajectory.

Here's a simplified approach to access the OBB and draw trajectories:

# Assuming 'results' contains your tracking output
for result in results:
    if result.boxes is not None:  # Check if boxes are detected
        for box in result.boxes.xyxy:  # Assuming xyxy format for simplicity
            # Calculate the center of the box
            center_x = (box[0] + box[2]) / 2
            center_y = (box[1] + box[3]) / 2
            # Draw or store the center point for trajectory plotting

Remember, this is a simplified example. You'll need to adapt it to handle OBB and track points across frames effectively.

Lastly, your appreciation for open-source developers is heartwarming! 🙏 If you have further questions or need more detailed assistance, feel free to ask. Happy coding!

[Morrison-Zhao]

Thank you very much for your reply and for resolving some of my confusion. But there are still some unclear aspects here.

The main problem is that the boxes in my result are always None, which makes me a bit confused. But in fact, I have already identified the target vehicle in my output video. I guess the problem may arise from my access to OBB's internal information.

This is some information I got from debugging:

Thank you again for your patience and professionalism.^_^

[pderrenger]

Hey there! 😊 It looks like you're making great progress with your vehicle recognition and tracking project using YOLOv8 OBB. I'm here to help clarify your concerns about accessing the oriented bounding boxes (OBB) and drawing motion trajectories.

If your results.boxes are always None, but you're still seeing the detected vehicles in your output video, it might be due to how you're accessing the results. For OBB models like yolov8n-obb.pt, the bounding boxes are stored a bit differently. Here's a quick way to access them:

# After tracking
if results.boxes is not None:
    for box in results.boxes.xyxy[0]:  # Accessing the first image's boxes
        # Your code to process each box
        print(box)

Regarding the persist and stream parameters:

• persist=True helps in maintaining object IDs across frames, crucial for tracking their trajectories.
• stream=True optimizes processing for video streams, especially useful for long or live video feeds.

For drawing trajectories, you indeed need to track the center points of each vehicle's bounding box across frames. Here's a simplified approach:

# Assuming you have a way to track centers across frames
centers = []  # List to store center points
for box in results.boxes.xyxy[0]:
    center_x = (box[0] + box[2]) / 2
    center_y = (box[1] + box[3]) / 2
    centers.append((center_x, center_y))

# Now, you can draw lines between consecutive centers to show trajectories

Remember, this is just a starting point. You'll need to adapt it to track and connect these centers across multiple frames effectively.

Thanks for reaching out, and don't hesitate to ask if you have more questions. Keep up the great work! 🚀

[Morrison-Zhao]

Thank you for your help. I have also made new breakthroughs here.

I carefully read the source code and found that the problem lies in the fact that boxes and obb are interchangeable codes as follows:

So if I need to access boxes, the actual operation required is this code:

`

        results = model.track(frame, persist=True)
        # Get the first result
        first = results[0]

        # Get the current track center points, mapped by the object id
        # change: result.boxes---->result.obb
        current_points: dict[int, Point] = {int(obb.id[0]): (int(obb.xywhr[0][0]), int(obb.xywhr[0][1])) for i, obb in enumerate(first.obb or first.boxes)}

        # Annotate current frame with labels and bounding boxes
        annotated_frame = first.plot(labels=show_labels, font_size=label_size, boxes=show_boxes, line_width=box_thickness)

`

I am now able to successfully draw the motion trajectory! Thank you again for your help, and I hope the official can provide a more detailed explanation of the use of this code, so that more coders can have a better experience!

[pderrenger]

Hey there! 🎉 It's fantastic to hear about your breakthroughs and progress with the YOLOv8 OBB model for vehicle recognition and tracking. You've done a great job diving into the source code and figuring out the solution to access the oriented bounding boxes (OBB) correctly. Your approach to using result.obb instead of result.boxes for OBB models is spot on!

For drawing motion trajectories, your method of mapping current track center points by object ID and then plotting them is a solid strategy. It's great to see you've successfully implemented it.

Regarding the persist and stream parameters:

• persist=True is crucial for tracking as it maintains object IDs across frames, allowing you to draw continuous trajectories.
• stream=True optimizes processing for video streams, especially useful for long or live video feeds.

Your contribution and feedback are invaluable, and it's insights like yours that help improve the experience for everyone in the community. We'll definitely consider providing more detailed examples and explanations in our documentation to make it easier for coders to utilize these features effectively.

Keep up the amazing work, and don't hesitate to reach out if you have more questions or insights to share! Happy coding! 🚀

[liu15509348793]

Thanks for the work, how did the pre-training weights of yolov8s-obb get obtained? How should the training parameters be set, I can't train with the map in the documentation

[liu15509348793]

去csdn看看吧，我记得是要下载数据集和配置一些yaml文件的。太久没看了，当时做毕设用的。

我可以正常训练，就是精度达不到官网预训练权重的精度，数据按照配置都整好了

[Morrison-Zhao]

显卡性能够的话可以尝试增加批次，然后得看你用的什么数据集，其他的参数我就不太懂了。

[liu15509348793]

显卡性能够的话可以尝试增加批次，然后得看你用的什么数据集，其他的参数我就不太懂了。

数据集一样，batch16,所以我就想问一下官方这个预训练权重是怎么得到的，不知道他们训练参数怎么设置的

[Morrison-Zhao]

直接去官方下面的issue拷打他们（狗头

[glenn-jocher]

The pre-trained weights for YOLOv8s-obb are obtained by training on the DOTAv1 dataset. To achieve similar mAP, ensure your dataset is correctly formatted and consider adjusting hyperparameters like learning rate, batch size, and epochs. For detailed guidance, refer to the Ultralytics documentation.

[QLGalaxy]

Hi！Thanks for this work. Recently I tried the pretrained model yolov11n-obb and the model trained by myself with the same params and network, but my model seems to be worse. I used them to predict objects on a parking lot image, yolov11n-obb.pt can easily find the small-vehicles but mine can't. What's going wrong?
PS : The dataset is DOTAv1 and was splited into 1024*1024 size

[QLGalaxy]

其实跟上面那个同学问题差不多，就是用官方的训练方法也达不到相应map。不光是mAP上的差别，在实际测试的性能上也差了不少，我上面提的是一个具体的例子。不过yolo11确实是新的，所以不知道他们有没有用什么奇奇怪怪的预训练权重（

[Morrison-Zhao]

我之前其实训练的效果也不好，经常会有误检和漏检的情况。但是当时也没深究哈哈，所以这块儿我不是很了解

[glenn-jocher]

@ZzMLvzZ-792998470 it sounds like your custom-trained model isn't performing as well as the pretrained YOLO11n-obb model. Ensure your dataset is correctly formatted and that you're using the same training parameters. Differences in data augmentation, learning rate, or other hyperparameters can impact performance. For more insights, you might want to revisit the training configuration or explore additional fine-tuning. If issues persist, consider checking the Ultralytics documentation for guidance.

[QLGalaxy]

Maybe my requirement is about HOW to reach the mAP of your pretrained model, I‘ve tried the params, networks, and everything the same in the documents, but still have a distance with your model

[glenn-jocher]

If your custom-trained model isn't matching the pretrained YOLO11n-obb performance, consider checking your data augmentation techniques, learning rate, and other hyperparameters. Ensure your dataset is correctly formatted and that you're using the same training setup. For further insights, revisit the Ultralytics documentation.

[Oct-Sunn]

Hello, I am training the DOTA v1 dataset using the YOLOv11n model and encountered an issue. While the model parameters match the pre-trained model size from the official website (2.7M), the computational load is only 6.7 GFLOPs, which is significantly lower than the 17.2 GFLOPs listed on the website. This discrepancy may be causing the performance gap, as my training accuracy is far from the official 78.4. I’ve already changed the task to OBB. Could you please help me understand what might be causing this issue? Thank you!

[glenn-jocher]

@SunPengYuan-HairenD the discrepancy in GFLOPs may result from differences in input image size, batch size, or hardware configuration during inference. Ensure you are using a consistent image size (e.g., 1024x1024 for YOLO11n-OBB) and validate the model with the same configurations as listed in the official benchmarks. For more details, refer to the OBB documentation. Let us know if you need further clarification!

[Oct-Sunn]

Thank you very much for your reply. The results of the above operation have been configured according to the instruction document, and the picture size is 1024x1024. Strangely, when I run Detect and Segment (using the official data set specified on the official website as well), this situation doesn't occur. The number of parameters and the amount of computation can correspond to those of the pre-trained model on the official website. Moreover, I'm using the same device, so input image size, batch size, or hardware configuration during inference can all be excluded. Therefore, I still haven't figured out what exactly causes this problem. Could you please offer further assistance?

[glenn-jocher]

Thank you for clarifying. If the GFLOPs discrepancy persists despite consistent configurations, it may stem from how the model is initialized or optimized during training. Verify that the yolo11n-obb.pt weights are correctly loaded and ensure no unintended modifications to the model architecture in your training script. Additionally, try revalidating your setup against the official OBB guide and consider running the model on a fresh environment to rule out any hidden dependencies. Let us know if the issue persists!

[LiangChaoWei512]

Hello, I would like to ask what rules the predicted arc is calculated according to, and whether there is a range for the predicted arc.

[glenn-jocher]

@LiangChaoWei512 the predicted angle (arc) in OBB models represents rotation in radians and is calculated relative to the horizontal axis. Angles are typically normalized between 0 and π radians (0-180°) to avoid redundancy. For implementation details, see our OBB dataset format guide at https://docs.ultralytics.com/datasets/obb and predict mode documentation at https://docs.ultralytics.com/modes/predict.

[SimmonQAQ]

Hello, I would like to ask why there is a difference between the predicted output of model. val() and model () in the YOLO11 OBB object detection task when the model weights, dataset, and hyperparameters are the same. I believe that in this situation where there is a difference, the evaluation metrics output by model. val() are not very useful

[glenn-jocher]

@SimmonQAQ the remaining differences between model.val() and model() predictions in OBB tasks likely stem from additional default parameters not explicitly set in your code. Key factors to check/align include:

1. Input preprocessing (ensure matching imgsz)
2. Postprocessing parameters like max_det
3. Augmentation settings (augment=False for both)

For full parity, explicitly set all inference parameters in both modes using the Configuration guide.

[SimmonQAQ]

Hello, according to the configuration file, I have set the parameters of model() and model-val() to be equal, but the output of model() still does not match the result in 'val_match0ulabels. jpg' output of model-val(). Here is my code

model.val():
from ultralytics import YOLO
import os
os.environ['KMP_DUPLICATE_LIB_OK'] = 'TRUE'

if name == 'main':
model = YOLO('runs/obb/result/yolo11n/weights/epoch147.pt')
results = model.val(
data='datasets/short_dataset/data.yaml',
# split='val',
project='runs/val/dataset',
name='yolo11n',
imgsz=640,
augment=False,
max_det=300,
iou=0.18,
conf=0.25,
rect=True,
half=False,
nms=True,
dnn=False,
vid_stride=1,
stream_buffer=False,
visualize=False,
agnostic_nms=False,
retina_masks=False
)

model():
from ultralytics import YOLO

model = YOLO('runs/obb/result/yolo11n/weights/epoch147.pt')
results = model('datasets/short_dataset/valid/images/20250122082212-AD.jpg',
show=True,
imgsz=640,
augment=False,
max_det=300,
iou=0.18,
conf=0.25,
rect=True,
half=False,
nms=True,
dnn=False,
vid_stride=1,
stream_buffer=False,
visualize=False,
agnostic_nms=False,
retina_masks=False
)

[glenn-jocher]

The remaining differences likely stem from input preprocessing nuances. Ensure your model() predictions use the same image normalization as model.val(), which automatically converts images to RGB and applies scaling. Try converting your OpenCV-loaded BGR images to RGB before inference:

image = cv2.cvtColor(cv2.imread(image_path), cv2.COLOR_BGR2RGB)
results = model(image, ...)

For full parity, review the preprocessing steps in the Val mode implementation.

[SimmonQAQ]

After modifying the code, the results of model () and model. val() are still inconsistent. This is my modified code:

import cv2
from ultralytics import YOLO

model = YOLO('runs/obb/result/yolo11n/weights/epoch147.pt')
image_path = 'datasets/short_dataset/valid/images/20250122082212-AD.jpg'
image = cv2.imread(image_path)
image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB)
results = model(image,
show=True,
imgsz=640,
augment=False,
max_det=300,
iou=0.18,
conf=0.25,
rect=True,
half=False,
nms=True,
dnn=False,
vid_stride=1,
stream_buffer=False,
visualize=False,
agnostic_nms=False,
retina_masks=False
)

[glenn-jocher]

To address the remaining differences between model() and model.val() outputs in OBB tasks, please verify that your validation dataset YAML file includes the exact class names and label mappings used during training. Small discrepancies in label handling between validation and prediction modes can cause output mismatches even with identical parameters. For full implementation details, refer to the Oriented Bounding Boxes documentation.

[SimmonQAQ]

Hello, may I ask what is the basis for calculating the precision and recall of model. val() in OBB detection? I noticed that they do not match the data listed in the confusion matrix returned. For example, if TP is 204 and FP is 20 in the confusion matrix returned, the traditional precision should be 204/224=0.91. However, I found that the precision returned is not equal to 0.91

[glenn-jocher]

@SimmonQAQ thank you for your question! For OBB detection, precision and recall calculations use rotated IoU (R-IoU) between predicted and ground truth boxes rather than axis-aligned IoU. This means TP/FP counts are determined based on oriented box overlap thresholds, which can differ from traditional axis-aligned detection metrics. For single-class tasks, this R-IoU calculation still applies.

For implementation details, see the OBB Validation Metrics section in our docs. Let us know if you need further clarification! 🚀

[SimmonQAQ]

Sorry, I still don't quite understand. For OBB tasks, should I trust the precision and recall returned by model. val() or the confusion matrix returned by model. val()?

[glenn-jocher]

For OBB tasks, the precision and recall returned by model.val() are accurate as they use rotated IoU calculations specific to oriented boxes. The confusion matrix may not fully reflect OBB-specific metrics due to differences in IoU computation methods. We recommend trusting the model.val() metrics for OBB evaluation. For details, see the OBB validation metrics documentation.

[SimmonQAQ]

OK，thanks

[glenn-jocher]

You're welcome! If you have any more questions as you work with OBB detection, feel free to ask. We're here to help. 🚀

[LiangChaoWei512]

Hello, I use the 1280 size to train the yolo11sobb model in my own dataset. Most of my detection targets are slender types with a very large aspect ratio. Then I use the trained weights to predict, and the predicted box is always much shorter than the box I want. Including when I predict on my training data, the length of the predicted box is also much shorter than the length of the box I annotated. Why is this?

[glenn-jocher]

@LiangChaoWei512 thanks for your question! For slender objects with high aspect ratios in OBB detection, ensure your dataset annotations are correctly normalized in the YOLO OBB format (four corners with 0-1 coordinates) and verify your training configuration matches the input size and aspect ratios of your targets. You might also benefit from adjusting anchor sizes in your model YAML to better match your objects' proportions. For details, see the Oriented Bounding Boxes Dataset Guide.

[cripsgreen]

Hello, I would like to know how you trained the YOLOv11n-OBB model. What hyperparameters did you use? Did you use any pretrained weights? If so, which dataset was used for pretraining?

I used the COCO dataset for pretraining and trained it for 50 epochs, then fine-tuned it on the DOTA v1 dataset. However, the final mAP50 on DOTA v1 is only slightly above 0.51, which is far from the expected 0.8. Could you please share some of the training hyperparameters you used?

[ziishuo]

May I ask if the OBB model can be used to detect subjects in a normal perspective (such as a level shot)? I noticed that most of the examples are from a top-down angle. Thank you!

[cripsgreen]

Hello, could you please share some insights on how to train the hyperparameters for YOLOv11-OBB, as well as the pre-trained weights? Thank you.

[wang18382140151-hub]

你好，请问你们未来的工作计划中是否有将rtdetr用于obb检测呢，最近我正在基于贵司源码做改进

[kssion]

WARNING ⚠️ CoreML: 'nms=True' is only available for Detect models like 'yolo11n.pt'.

yolo export model=best.pt format=coreml nms=True conf=0.25 iou=0.45

Ultralytics 8.3.232 🚀 Python-3.11.11 torch-2.9.1 CPU (Apple M1)
YOLO11n-obb summary (fused): 109 layers, 2,653,918 parameters, 0 gradients, 6.6 GFLOPs

PyTorch: starting from 'best.pt' with input shape (1, 3, 640, 640) BCHW and output shape(s) (1, 6, 8400) (5.5 MB)
Torch version 2.9.1 has not been tested with coremltools. You may run into unexpected errors. Torch 2.7.0 is the most recent version that has been tested.

CoreML: starting export with coremltools 9.0...
WARNING ⚠️ CoreML: 'nms=True' is only available for Detect models like 'yolo11n.pt'.
Converting PyTorch Frontend ==> MIL Ops: 100%|██████████████▉| 867/868 [00:00<00:00, 8975.73 ops/s]
Running MIL frontend_pytorch pipeline: 100%|███████████████████| 5/5 [00:00<00:00, 166.58 passes/s]
Running MIL default pipeline: 100%|███████████████████████████| 95/95 [00:00<00:00, 99.61 passes/s]
Running MIL backend_mlprogram pipeline: 100%|████████████████| 12/12 [00:00<00:00, 176.60 passes/s]
CoreML: export success ✅ 4.8s, saved as 'best.mlpackage' (5.3 MB)

Export complete (5.0s)

[glenn-jocher]

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