Fix TFLite INT8 for OBB

[adamp87]

This PR fixes the bug when exporting OBB model for TFLite with INT8 quantization. During normalization dist2bbox is used instead of dist2rbox.

NOTE: tests have been executed using the validation set. The test set is missing the labels. TFLite quantization was set to per-channel.

Model	mAP50	mAP50:95	Note
Before yolov8n-obb.pt	0.468	0.283
Before yolov8n-obb.TFLite INT8	0.375	0.245
Before yolov8n-obb.TFLite Full INT	0.305	0.175
After yolov8n-obb.pt	0.468	0.283
After yolov8n-obb.TFLite INT8	0.496	0.355	How?
After yolov8n-obb.TFLite Full INT	0.394	0.244

Reproduce tests:

yolo export model=yolov8n-obb.pt data=coco128.yaml imgsz=640 format=tflite int8
yolo val obb model=yolov8n-obb.pt data=DOTAv1.yaml device=0 imgsz=640 batch=4 split=val
yolo val obb model=yolov8n-obb_saved_model/yolov8n-obb_int8.tflite data=DOTAv1.yaml device=0 imgsz=640 int8 split=val
yolo val obb model=yolov8n-obb_saved_model/yolov8n-obb_full_integer_quant.tflite data=DOTAv1.yaml device=0 imgsz=640 int8 split=val

It is surprising to observe that the TFLite INT8, where only weights are INT8 and inference is in FP32, is performing better than the original PyTorch model. This should be further tested, but I am not familiar with the OBB neither with DOTA dataset. Theoretically the only difference is that the bbox coordinates are normalized. Could it have an influence on the bbox rotations?

🛠️ PR Summary

_{Made with ❤️ by Ultralytics Actions}

🌟 Summary

Refactor of bounding box decoding in neural network heads to improve flexibility.

📊 Key Changes

• decode_bboxes method now takes anchors as an argument instead of using self.anchors.
• Bounding box decoding operation has been updated within the forward method of the network to better handle different conditions, such as when exporting models to TensorFlow Lite or Edge TPU.
• Calls to dist2bbox and dist2rbox now directly pass calculated bounding boxes and anchors.

🎯 Purpose & Impact

• 💡 Purpose: The changes aim to improve the stability and flexibility of bounding box decoding across different network heads and export formats.
• 🔍 Impact: Developers will have an easier time adapting and maintaining the bounding box decoding logic for different use cases, potentially resulting in better model compatibility and performance when exporting to various platforms.
• 🚀 To users: These updates might lead to more accurate object detections and support for broader deployment scenarios, especially for edge computing devices.

🛠️ PR Summary

_{Made with ❤️ by Ultralytics Actions}

🌟 Summary

Optimized bounding box decoding for model export compatibility.

📊 Key Changes

• Modified decoding of bounding boxes in the forward function based on export conditions.
• Added anchors as an argument to both decode_bboxes and decode_bboxes methods to clarify input requirements.
• Applied stride normalization directly within the decode_bboxes method when not exporting.
• Renamed variables (img_h -> grid_h, img_w -> grid_w, img_size -> grid_size) for clarity in the context of grid dimensions.

🎯 Purpose & Impact

• The update aims to improve numerical stability for exported models, particularly those targeting platforms like TFLite and Edge TPU. 🤖
• Enhances code readability and maintainability through clearer naming conventions and streamlined decoding logic. 📖
• Users targeting different deployment environments can expect more reliable model performance and easier integration with hardware accelerators. 🚀

[sentry-io]

🔍 Existing Issues For Review

Your pull request is modifying functions with the following pre-existing issues:

📄 File: ultralytics/nn/modules/head.py

Function	Unhandled Issue
forward	RuntimeError: The size of tensor a (6400) must match the size of tensor b (8400) at non-singleton dimension 2 ... Event Count: 1

---

_{Did you find this useful? React with a 👍 or 👎}

[adamp87]

_I have read the CLA Document and I hereby sign the CLA_

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (9d35ecb) 78.78% compared to head (88b4ce1) 76.67%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7989      +/-   ##
==========================================
- Coverage   78.78%   76.67%   -2.12%     
==========================================
  Files         117      117              
  Lines       14455    14455              
==========================================
- Hits        11389    11083     -306     
- Misses       3066     3372     +306     

Flag	Coverage Δ
Benchmarks	36.42% <100.00%> (ø)
GPU	39.33% <40.00%> (ø)
Tests	71.69% <50.00%> (-2.66%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[glenn-jocher]

@adamp87 thank you for signing the CLA! Your contribution is greatly appreciated. 🌟 If you have any further questions or need assistance, feel free to reach out.

[glenn-jocher]

@adamp87 based on the table it seems like something may be wrong in the PR, as it should not be possible to increase mAP beyond the base PyTorch model.

@Laughing-q what do you think?

[Laughing-q]

@adamp87 Thanks for the fix!
@glenn-jocher @adamp87 The map from torch model is lower because we default use rectangle inference when doing validation with torch model, but for exported model it's square inference. The map looks fine when I manually set rect=False.

yolo val obb model=yolov8n-obb.pt data=DOTAv1.yaml device=0 imgsz=640 batch=4 split=val

                   all        458      28853      0.698       0.43      0.468      0.283
                 plane        458       2531      0.804      0.629      0.668      0.414
                  ship        458       8960      0.735      0.478      0.555      0.286
          storage tank        458       2888      0.847      0.231      0.347      0.182
      baseball diamond        458        214      0.776      0.435      0.525       0.34
          tennis court        458        760       0.91      0.883      0.912      0.704
      basketball court        458        132      0.637      0.348      0.411       0.29
    ground track field        458        144      0.585      0.361      0.391      0.272
                harbor        458       2090      0.565      0.537      0.503       0.22
                bridge        458        464      0.606      0.127      0.149     0.0507
         large vehicle        458       4387       0.76      0.767      0.784      0.471
         small vehicle        458       5438       0.66      0.496      0.545       0.33
            helicopter        458         73      0.767      0.288      0.334      0.181
            roundabout        458        179      0.617      0.128       0.16     0.0962
     soccer ball field        458        153      0.553      0.392       0.37      0.229
         swimming pool        458        440      0.646      0.344      0.363      0.175

yolo val obb model=yolov8n-obb.pt data=DOTAv1.yaml device=0 imgsz=640 batch=4 split=val rect=False

                   all        458      28853      0.729      0.447      0.496      0.356
                 plane        458       2531      0.853      0.672      0.724      0.537
                  ship        458       8960      0.766      0.494      0.574      0.351
          storage tank        458       2888      0.863      0.234      0.365      0.228
      baseball diamond        458        214      0.764       0.43      0.525      0.393
          tennis court        458        760      0.908      0.882      0.917      0.846
      basketball court        458        132      0.642      0.356       0.42      0.349
    ground track field        458        144      0.583      0.389      0.388      0.327
                harbor        458       2090       0.74      0.704       0.72      0.398
                bridge        458        464      0.658      0.137      0.166      0.058
         large vehicle        458       4387      0.793       0.79      0.819      0.608
         small vehicle        458       5438      0.676       0.49      0.551      0.358
            helicopter        458         73      0.887      0.329      0.404       0.28
            roundabout        458        179      0.644      0.123      0.156      0.112
     soccer ball field        458        153      0.507      0.346      0.365       0.31
         swimming pool        458        440      0.655      0.336      0.353      0.185

And the reason why the map is lower with rect=True I think is because most of the training samples are square images(1024x1024).

[adamp87]

@Laughing-q thanks for the clarification. It was bugging me also!
@glenn-jocher I pushed one more commit. I changed only variables names during normalization, where the normalization is done with the width and height of the grid not the input image size.

[adamp87]

@glenn-jocher one more note, OpenVINO INT8 quantization fails on main branch with nncf: list index out of range. I just pulled the repo now. The suggested solution in #7516 (comment) fixes this problem.

yolo export model=yolov8n-obb.pt data=coco128.yaml imgsz=640 format=openvino int8

Model	mAP50	mAP50:95	Note
After yolov8n-obb.pt	0.468	0.283
After yolov8n-obb.pt	0.497	0.356	rect=False
After yolov8n-obb.TFLite INT8	0.496	0.355	per-channel
After yolov8n-obb.TFLite Full INT	0.394	0.244	per-channel
After yolov8n-obb.TFLite INT8	0.489	0.349	per-tensor
After yolov8n-obb.TFLite Full INT	0.394	0.244	per-tensor
OpenVINO INT8	N/A	N/A	Main branch fails
OpenVINO INT8	0.493	0.352	#7516 (comment)

[glenn-jocher]

@adamp87 thank you for your efforts here! I've merged this into main now. I was reviewing #7516 (comment) but we can't merge this as it's failing OpenVINO Benchmarks CI on main.

Now that I've merged this to main I will re-run the CI there to see if this now passes.

[adamp87]

@glenn-jocher thanks for the update.
Im confused on the #7516 (comment) comment. Do you mean #7516 (comment) or the PR #7516? They are two different things. I havent merged #7516 (comment) into the PR its just in my own fork dangling.

Maybe lets discuss it further in #7516

[glenn-jocher]

@adamp87 My apologies for the confusion. I was referring to the PR itself. Let's indeed continue this discussion in the PR thread to clarify and resolve any outstanding issues. Thank you for your contributions!