Best Configuration for Overhead Object Detection (1280x1024) with Small Objects

[smtalds-knt]

Search before asking

• I have searched the YOLOv5 issues and discussions and found no similar questions.

Question

Hi team,

I am working on an overhead object detection project using images with a resolution of 1280x1024. The objects are generally small (e.g., cars and people). The inference will be performed on the DPU. (B4096 or B3136) I am considering different approaches and would like your advice on the best configuration and workflow. Here is what I have explored so far:

• Training at 1280 resolution:
    ◦ If I train at 1280x1024, I can avoid resize operations during preprocessing and postprocessing. 
    ◦ This could potentially save some FPS, but I am not sure how much it will impact inference performance overall. The DPU might actually spend more time processing larger inputs.

• Training at 640x640 or 640x512 (custom) resolution and using a Nano or Small model:
    ◦ This approach should increase FPS on the DPU.
    ◦ However, I have observed that small objects are often missed in detection results.

• Dataset preparation:
    ◦ I am creating my own dataset.
    ◦ With augmentation, I can expand it to around 10,000 images.
    ◦ One challenge is that the object distribution between classes is not balanced (e.g., different frequencies of cars and people).

Questions:
1. What do you recommend as the best resolution and model size combination to balance FPS and detection accuracy, especially for small objects?
2. Is it worth training directly at 1280 resolution to avoid resizing, or would you expect diminishing returns on accuracy vs. performance?
3. Do you have any recommendations for dataset preparation and augmentation to improve performance and balance between classes?
Any guidance or suggestions would be greatly appreciated.
Thank you!

Additional

No response

[UltralyticsAssistant]

👋 Hello @smtalds-knt, thank you for your interest in YOLOv5 🚀! Your project sounds interesting, and these are great questions regarding balancing accuracy and performance for overhead object detection with small objects.

This is an automated response to help you get started—an Ultralytics engineer will review your issue and assist you soon! In the meantime, here are some helpful resources:

Please visit our ⭐️ Tutorials to get started, where you can find quickstart guides for simple tasks like Custom Data Training all the way to advanced concepts like Hyperparameter Evolution.

If this is a 🐛 Bug Report, please provide a minimum reproducible example to help us debug it.

If this is a custom training ❓ Question (like yours), please provide as much information as possible, including:

• Dataset image examples and training logs
• Details about your DPU environment
• Steps you've tried so far
• Confirmation you are following our Tips for Best Training Results

Requirements

Python>=3.8.0 with all requirements.txt installed including PyTorch>=1.8. To get started:

git clone https://github.com/ultralytics/yolov5  # clone
cd yolov5
pip install -r requirements.txt  # install

Environments

YOLOv5 may be run in any of the following up-to-date verified environments (with all dependencies including CUDA/CUDNN, Python and PyTorch preinstalled):

• Notebooks with free GPU:
• Google Cloud Deep Learning VM. See GCP Quickstart Guide
• Amazon Deep Learning AMI. See AWS Quickstart Guide
• Docker Image. See Docker Quickstart Guide

Status

If this badge is green, all YOLOv5 GitHub Actions Continuous Integration (CI) tests are currently passing. CI tests verify correct operation of YOLOv5 training, validation, inference, export and benchmarks on macOS, Windows, and Ubuntu every 24 hours and on every commit.

We appreciate your patience while our team reviews your questions! If you have additional info (such as sample images, config files, or logs), feel free to share them to help us assist you more efficiently. 👍

[pderrenger]

For small object detection, I'd recommend training at 1280 resolution with YOLOv5s or YOLOv5m as the best balance between accuracy and speed - smaller models at higher resolution often outperform larger models at lower resolution for small objects. Training at native 1280x1024 will likely provide better detection accuracy than downsampling, and while DPU inference will be slower, the accuracy gains typically justify the performance cost for small object scenarios.

For dataset preparation, use mosaic augmentation (enabled by default), consider copy-paste augmentation for small objects, and address class imbalance by using class weights in your training configuration - you can set cls: 0.5, 2.0 in your hyperparameters to weight the less frequent class higher. With 10k augmented images, ensure your validation split represents the actual deployment distribution rather than balanced classes.

Start with --img 1280 and YOLOv5s, then experiment with YOLOv5m if DPU performance allows - you can always optimize later with techniques like model pruning or quantization specifically for your DPU target.

[smtalds-knt]

Hi @pderrenger,
Thanks for answering.

1. I’ll try both S and M models as you suggested. Can I also use Nano models for this use case?
2. For custom training, should I start from pretrained weights (e.g., --weights yolov5n.pt) or only specify --cfg without any pretrained weights?
3. My last training command was as follows:

train: 
  weights=yolov5n.pt
  cfg=
  data=images.yaml
  hyp=data/hyps/hyp.scratch-low.yaml
  epochs=200
  batch_size=32
  imgsz=640
  rect=False
  resume=False
  nosave=False
  noval=False
  noautoanchor=False
  noplots=False
  evolve=None
  evolve_population=data/hyps
  resume_evolve=None

Based on this configuration, is my model considered Nano because I used --weights yolov5n.pt?

4. Also, what does mosaic augmentation mean (I understand it is enabled by default)? I didn’t see any explicit hyperparameters related to augmentation in the configuration. I assume I didn’t select any specific augmentation methods. For dataset preparation, I am using Roboflow.
5. Regarding your suggestion:

you can set cls: 0.5, 2.0 in your hyperparameters to weight the less frequent class higher.

Could you please provide a specific example of how to set this in hyp.yaml? I’m not sure I fully understand how to define this weighting.

Thank you very much for your help!

[pderrenger]

1. YOLOv5n can work but may struggle with very small objects - for 1280 resolution with small objects, I'd still recommend starting with YOLOv5s as the minimum viable model size.

2. Always use pretrained weights (--weights yolov5n.pt) rather than training from scratch - transfer learning from COCO pretrained weights will significantly improve your results, especially with a 10k image dataset.

3. Yes, using weights=yolov5n.pt means you're training a Nano model architecture - the model size is determined by the weights file you load, not the cfg parameter.

4. Mosaic augmentation combines 4 training images into one mosaic during training, helping the model learn to detect objects at different scales - it's controlled by the mosaic parameter in your hyperparameters file (default 1.0 means 100% of training uses mosaic).

5. I should clarify - for class imbalance in YOLOv5, you'll want to add class weights directly in your dataset yaml file like this:

train: path/to/train
val: path/to/val
nc: 2
names: ['car', 'person']
class_weights: [1.0, 2.0]  # weight person class 2x higher than car

For your 1280 resolution training, update your command to imgsz=1280 and consider batch_size=16 or lower depending on your GPU memory.

[smtalds-knt]

Hi again @pderrenger,
Tabii! İşte GitHub'da yorum olarak kullanabileceğin şekilde yazılmış İngilizce açıklama:

Hi, training is still ongoing. As you know, I will need to perform custom inference on the DPU.

My dataset images are in 1280x1024 resolution, and I’m training the model with --imgsz 1280. I’m a bit confused after reading other issues.
For inference on the DPU, should the input image be 1280x1024 (original size), or do I need to resize/scale it to 1280x1280 to match the training shape?

Thanks in advance!

[pderrenger]

For inference, you should feed your original 1280x1024 images directly to the model - YOLOv5 will automatically handle the preprocessing to convert them to the square 1280x1280 format used during training. The model applies letterboxing (resizing while maintaining aspect ratio and padding) to convert your rectangular images to square inputs, just like it did during training.

When you run inference with python detect.py --weights your_model.pt --source your_images --imgsz 1280, YOLOv5 will automatically preprocess your 1280x1024 images to 1280x1280 internally, then scale the detection results back to your original image coordinates. No manual resizing is needed on your part.

[smtalds-knt]

Ah, I see — I think I misunderstood earlier. I assumed that by training with --imgsz 1280, I could perform custom inference directly using 1280x1024 images without any resizing. Since I’m handling preprocessing on hardware, upscaling to 1280x1280 introduces unwanted latency.

However, the training improvements you mentioned really helped — I’m seeing promising results in my confusion matrix. Thanks for that!
One thing I’d like to improve: the Car vs. Background classification is still showing some confusion.
Do you have any suggestions on how I could improve the model's performance specifically in that area?

[pderrenger]

To improve car vs background classification, try these approaches: increase your dataset diversity with more varied backgrounds where cars appear, ensure your negative samples (background-only images) are well-represented during training, and consider lowering your confidence threshold during inference to reduce false negatives while using stricter NMS settings to reduce false positives.

You can also experiment with the obj loss weight in your hyperparameters file - try increasing it to obj: 1.5 or obj: 2.0 to help the model better distinguish between objects and background. Additionally, review your labeling consistency, especially around partially occluded cars or cars at image edges, as these often contribute to background confusion.

For your hardware preprocessing concern, if you need to avoid the 1280x1024 → 1280x1280 conversion, you could retrain with a custom rectangular input size, but this would require modifying the model architecture and isn't straightforward with standard YOLOv5 - the performance gains from training at native 1280x1024 would likely be minimal compared to the complexity involved.

[smtalds-knt]

These results are with obj: 1.5. I’m planning to try obj: 2.0 next — hopefully that will improve things.
The car objects have very few pixels in many cases, so perhaps the current results are reasonable given the small size. But I’ll experiment further and see if there's room for improvement.

[pderrenger]

Great progress on your results! For very small car objects, those metrics are actually quite good - small object detection inherently has these challenges.

Since you're already experimenting with obj: 2.0, also try slightly increasing the cls loss weight to cls: 0.7 or cls: 0.8 to help with the classification component. You might also benefit from training longer - consider extending to 300-400 epochs since small objects typically need more training iterations to converge well.

Given the pixel-sparse nature of your car objects, your current performance is reasonable, and the incremental improvements from obj: 2.0 should help reduce those background false positives while maintaining detection sensitivity.

[smtalds-knt]

• Yes, i am training with 300 epochs.
• I tried cls: 0.7 , but there is not improvement.
• I am editing dataset now. I saw some bad bbox and data in dataset.

[pderrenger]

Good approach with the dataset cleaning - bad bounding boxes and mislabeled data have a disproportionate impact on small object detection performance. When reviewing your annotations, pay special attention to partially visible cars at image edges, ensure consistent labeling standards for very small cars (avoid labeling cars that are just a few pixels), and verify that your background regions don't accidentally contain unlabeled small cars.

After cleaning your dataset, the model should show clearer improvements in distinguishing cars from background - dataset quality often matters more than hyperparameter tuning for small object scenarios like yours.

[smtalds-knt]

• I feel like I may have reached the limit of what can be improved in this setup. Is it possible to eliminate the background class?

• How can I detect whether an object (e.g., a human face) is live or just an image (e.g., a photo or a printed face)? Is there any recommended technique or model architecture to implement liveness detection on top of object detection?