Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Add detection_threshold arg for all Lightning adapters
See original GitHub issue🚀 Feature
Is your feature request related to a problem? Please describe.
At the moment, the detection threshold for inside validation_step is at or near zero for Lightning adapters. This results in pessimistic validation performance due to false positives.
https://github.com/airctic/icevision/blob/9abbb09f47e6fc18867a5aa662885b558af2975c/icevision/models/ross/efficientdet/lightning/model_adapter.py#L50
https://github.com/airctic/icevision/blob/9abbb09f47e6fc18867a5aa662885b558af2975c/icevision/models/ultralytics/yolov5/lightning/model_adapter.py#L51
Describe the solution you’d like A clear and concise description of what you want to happen. Add a kwarg in the init of the Lightning adapter
Describe alternatives you’ve considered A clear and concise description of any alternative solutions or features you’ve considered.
Additional context Happy to submit a PR if you guys agree
Issue Analytics
- State:
- Created 2 years ago
- Reactions:6
- Comments:12 (9 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
No problems at all, I totally agree with you guys. Thanks for the great discourse - I learnt a lot! 😊
I’ll go ahead and close the PR
I don’t think there is a need to close the PR. Your PR does not change the default metrics calculation behavior given the threshold is still set to 0. You are just exposing the parameter which is a good thing for potential future use cases. No? As far as I am concerned we could merge it.