Move yolox to object_detection module

[r-b-g-b]

Closes #139

The cycle we're up against:

• data.video.load_video_frames
• models.megadetector_lite_yolox
• models.init
• models.efficientnet_models
• pytorch_lightning.utils.ZambaVideoClassificationLightningModule
• data.video.VideoLoaderConfig

In summary, the frame loader needs YoloX, which is in zamba.models so calls that zamba.models.__init__, which instantiates all models for the registry. For example, efficientnet loads the base class ZambaVideoClassificationLightningModule, which loads the zamba.data.video.VideoLoaderConfig. And there's our cycle.

The simplest way to resolve the circular import issue seemed to be to move YoloX code out of models and into its own zamba.object_detection module.

I updated the docs to reflect that; I think I caught everything.

[github-actions]

🚀 Deployed on https://deploy-preview-167--silly-keller-664934.netlify.app

[codecov]

Codecov Report

Merging #167 (f00257b) into master (b82c3f8) will increase coverage by 0.0%.
The diff coverage is 95.4%.

@@          Coverage Diff           @@
##           master    #167   +/-   ##
======================================
  Coverage    84.9%   85.0%           
======================================
  Files          28      30    +2     
  Lines        1839    1843    +4     
======================================
+ Hits         1563    1567    +4     
  Misses        276     276           

Impacted Files	Coverage Δ
zamba/__init__.py	100.0% <ø> (ø)
zamba/object_detection/yolox/yolox_base.py	18.7% <ø> (ø)
zamba/pytorch_lightning/utils.py	97.4% <ø> (+0.6%)	⬆️
zamba/models/registry.py	85.7% <85.7%> (ø)
zamba/data/video.py	79.7% <100.0%> (ø)
zamba/models/__init__.py	100.0% <100.0%> (ø)
zamba/models/efficientnet_models.py	100.0% <100.0%> (ø)
zamba/models/model_manager.py	84.1% <100.0%> (+<0.1%)	⬆️
zamba/models/slowfast_models.py	88.5% <100.0%> (+0.3%)	⬆️
zamba/object_detection/__init__.py	100.0% <100.0%> (ø)
... and 2 more

[pjbull]

Code change looks great to me pending tests passing 🎉 !

[ejm714]

Still curious if there's a simpler way. Seems like only importing VideoLoaderConfig in pytorch_lightning.utils for type checking might resolve this without needing to move YOLOX?

[pjbull]

I kind of like separating out object detection from the classification models, but I don't feel too strongly

[ejm714]

I kind of like separating out object detection from the classification models, but I don't feel too strongly

Agree this is a nice organization. We might end up further organizing our models directory then into classification vs. denspose vs. object detection. But this is sufficient for now

[r-b-g-b]

@ejm714 I did try that, which does fix the ZambaVideoClassificationLightningModule circular dependency, but there are other circular dependencies that show up then :/ I think that points to a pretty strong cycle in the code due to the fact that load_video_frames requires YoloX, YoloX is in models, which through models.__init__ ends up calling lots of model initialization code, including the dataloader, which needs load_video_frames. There might be another way to break the cycle by pulling the dataloader code out instead, but no guarantees that would solve it + I kind of like putting object detection in its own module.