🌟 Summary
CoreML export on iOS gets more reliable for detection models, fixing NMS issues with non-80-class datasets and simplifying model export handling. Plus, clearer download error messages for easier troubleshooting. 🚀
📊 Key Changes
- CoreML export robustness (priority):
- Adds an
mlprogram
path for iOS detection exports to handle MLProgram-specific behavior. - Pads class scores to the next multiple of 80 when NMS is enabled, working around a CoreML NMS bug for non-80-class models.
- Automatically reconciles class-name mappings if your model’s class count differs from provided names.
- Simplifies weight handling by using
ct_model.weights_dir
directly—no manual save-path juggling. - Details: see the Apple MLProgram NMS workaround PR ultralytics#22310 (addresses issue #22309).
- Adds an
- Downloads UX:
- More informative errors and warnings in
safe_download
, including underlying exception details for faster debugging. - Details: see the improved download diagnostics PR ultralytics#22308.
- More informative errors and warnings in
- Version bump to 8.3.207.
Minimal example (CoreML export with NMS):
yolo export model=yolo11n.pt format=coreml nms=True
# Now more reliable on iOS (MLProgram), even for non-80-class datasets 🎯
🎯 Purpose & Impact
- Reliable iOS deployments ✅: Fixes CoreML MLProgram NMS instability for detection models that don’t use 80 classes, reducing runtime errors and making exports “just work” on iOS.
- Correct labels out of the box 🏷️: Ensures class-name mapping stays accurate even when counts differ.
- Simpler exports 🧹: Cleaner weight handling reduces edge cases during CoreML export.
- Faster troubleshooting 🔍: Richer download error messages help users and CI pipelines quickly pinpoint network or permission issues.
What's Changed
- Update downloads.py to instrospect possible errors by @glenn-jocher in #22308
ultralytics 8.3.207
Apple MLProgram NMS models 80-class pad workaround by @Y-T-G in #22310
Full Changelog: v8.3.206...v8.3.207