You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Disclaimer: I have no affiliation with PyTorch Lightning, just an industry professional who wishes more research projects would make use of it 🙂
For v7 (or future YOLO versions), would you consider refactoring the code base to PyTorch Lightning? It is a much more organized way of presenting logic than vanilla PyTorch. This would make it significantly easier for other researchers/practitioners to re-use portions of your work without having to copy all dependencies of the original repository. From the maintainer's perspective, some additional benefits are that Lightning
Handles all the engineering pieces (DDP, mixed-precision, hardware accelerators, etc) which saves you a lot of (potentially error-prone) boilerplate code like this
Allows you to add auxiliary logic to the training process via callback hooks
For example, monitoring performance metrics to save model checkpoints: current > refactored
I think organising the codebase would be an excellent idea! As an alternative, I am the author of a lightweight library called PyTorch-accelerated, which I believe would require a lower refactoring effort than moving to Lightning as no changes would be required to the model or the datasets; the main refactoring effort required would be replacing the training logic with an implementation of a Trainer class.
If there interest in doing this @WongKinYiu@AlexeyAB, I could dedicate some time to assist with this effort; I have previously migrated the YoloX codebase which is very similar in many regards.
An update on this, myself and a colleague decided to undertake this effort. The results are detailed in this blog post, and the refactored code is in this repo.
Our implementation is compatible with the pretrained weights and is more aimed at people who want to understand Yolov7 under the hood or extend it for non-COCO use-cases, as opposed to replicating every detail of this repo.
Disclaimer: I have no affiliation with PyTorch Lightning, just an industry professional who wishes more research projects would make use of it 🙂
For v7 (or future YOLO versions), would you consider refactoring the code base to PyTorch Lightning? It is a much more organized way of presenting logic than vanilla PyTorch. This would make it significantly easier for other researchers/practitioners to re-use portions of your work without having to copy all dependencies of the original repository. From the maintainer's perspective, some additional benefits are that Lightning
Note: related work was completed for v3/4 in Lightning-Universe/lightning-bolts#552
The text was updated successfully, but these errors were encountered: