Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AutoShape integer image-size fix #10090

Merged
merged 2 commits into from
Nov 9, 2022
Merged

Conversation

janus-zheng
Copy link
Contributor

@janus-zheng janus-zheng commented Nov 9, 2022

We have a division at line 694, and then a multiplication at line 695, so it makes y*g not an integer. And since shape1 will be used at line 697 to ensure the size is divisible by the stride, this may lead to different image size.

In my experiment, my image is [640, 640], it's divisible by the default stride 32, but I found that the result is changed to [672, 672] after line 697. So the final detection result is slightly different from that directly using the detect.py script, which does not call the AutoShape methods.

Signed-off-by: janus-zheng [email protected]

🛠️ PR Summary

Made with ❤️ by Ultralytics Actions

🌟 Summary

Adjustment of image shape calculation for more reliable resizing in YOLOv5.

📊 Key Changes

  • Changed the resizing calculation to ensure image dimensions are integers after scaling.

🎯 Purpose & Impact

  • 🎨 Ensures that the image's new dimensions are precise integers, preventing potential errors or inconsistencies during image processing.
  • 💼 This minor but important tweak can lead to more robust performance of the model, as it avoids issues that can arise when non-integer dimensions are used in further processing steps.

We have a division at line 694, and then a multiplication at line 695, so it makes `y*g` not an integer. And since `shape1` will be used at line 697 to ensure the size is divisible by the `stride`, this may lead to different image size.

In my experiment, my image is [640, 640], it's divisible by the default stride 32, but I found that the result is changed to [672, 672] after line 697. So the final detection result is slightly different from that directly using the `detect.py` script, which does not call the AutoShape methods. 


Signed-off-by: janus-zheng <[email protected]>
@janus-zheng janus-zheng changed the title Update common.py Type issue of image shape may lead to different detection results Nov 9, 2022
Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👋 Hello @janus-zheng, thank you for submitting a YOLOv5 🚀 PR! To allow your work to be integrated as seamlessly as possible, we advise you to:

  • ✅ Verify your PR is up-to-date with ultralytics/yolov5 master branch. If your PR is behind you can update your code by clicking the 'Update branch' button or by running git pull and git merge master locally.
  • ✅ Verify all YOLOv5 Continuous Integration (CI) checks are passing.
  • ✅ Reduce changes to the absolute minimum required for your bug fix or feature addition. "It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is." — Bruce Lee

@glenn-jocher
Copy link
Member

@janus-zheng interesting! Thanks for the PR!

@glenn-jocher glenn-jocher changed the title Type issue of image shape may lead to different detection results AutoShape integer image-size fix Nov 9, 2022
@glenn-jocher glenn-jocher self-assigned this Nov 9, 2022
@glenn-jocher glenn-jocher merged commit 892c4cd into ultralytics:master Nov 9, 2022
@glenn-jocher
Copy link
Member

@janus-zheng PR is merged. Thank you for your contributions to YOLOv5 🚀 and Vision AI ⭐

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants