Update YOLO-NAS submissions with super_gradients-parity preprocessing#6
Open
EHxuban11 wants to merge 1 commit into
Open
Update YOLO-NAS submissions with super_gradients-parity preprocessing#6EHxuban11 wants to merge 1 commit into
EHxuban11 wants to merge 1 commit into
Conversation
The first YOLO-NAS submission set (merged in #5) used LibreYOLO's existing shared letterbox preprocessing, which differs from super_gradients' YOLO-NAS COCO validation pipeline in two ways the file's own docstring already flagged ("A later parity pass can tighten this toward the exact SG processing pipeline"): - longest-side resize to 640 instead of 636 - top-left padding instead of center padding to 640x640 Closing those two gaps (plus moving the harness's NMS IoU from 0.6 to 0.7 to match super_gradients' default) recovers ~60% of the 1-point gap to Deci's published numbers. LibreYOLO upstream issue + working branch (113-yolo-nas-validation- preprocessing-diverges-from-super_gradients-map-loss) covers the actual code change. libreyolo_commit on these submissions stays "unknown" until the fix is merged into LibreYOLO main and a pinned commit is added to support-matrix.json. Numbers (COCO val2017, A100 PyTorch FP32): yolonas-s 0.4711 (prev 0.4645, paper 0.475) yolonas-m 0.5111 (prev 0.5053, paper 0.516) yolonas-l 0.5184 (prev 0.5119, paper 0.522) Remaining ~0.005 gap per variant is consistent across s/m/l and likely reflects FP16 vs FP32 plus minor cv2 vs PIL interpolation differences. Local: scripts/validate_submission.py and scripts/build_verified_results.py both exit 0. generated/verified-results.v1.json regenerated.
EHxuban11
force-pushed
the
benchmark/a100-pytorch-cuda-yolonas-v2-preprocessing-fix
branch
from
ba7b279 to
97042a4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The first YOLO-NAS submission set (merged in #5) used LibreYOLO's existing shared letterbox preprocessing, which differs from super_gradients' YOLO-NAS COCO validation pipeline in two ways the file's own docstring already flagged ("A later parity pass can tighten this toward the exact SG processing pipeline"):
Closing those two gaps (plus moving the harness's NMS IoU from 0.6 to 0.7 to match super_gradients' default) recovers ~60% of the 1-point gap to Deci's published numbers.
LibreYOLO upstream issue + working branch (113-yolo-nas-validation- preprocessing-diverges-from-super_gradients-map-loss) covers the actual code change. libreyolo_commit on these submissions stays "unknown" until the fix is merged into LibreYOLO main and a pinned commit is added to support-matrix.json.
Numbers (COCO val2017, A100 PyTorch FP32):
yolonas-s 0.4711 (prev 0.4645, paper 0.475)
yolonas-m 0.5111 (prev 0.5053, paper 0.516)
yolonas-l 0.5184 (prev 0.5119, paper 0.522)
Remaining ~0.005 gap per variant is consistent across s/m/l and likely reflects FP16 vs FP32 plus minor cv2 vs PIL interpolation differences.
Local: scripts/validate_submission.py and scripts/build_verified_results.py both exit 0. generated/verified-results.v1.json regenerated.