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

Reorganize project directories #140

Open
MedericFourmy opened this issue Feb 21, 2024 · 3 comments
Open

Reorganize project directories #140

MedericFourmy opened this issue Feb 21, 2024 · 3 comments

Comments

@MedericFourmy
Copy link
Collaborator

MedericFourmy commented Feb 21, 2024

For now, happypose main folders are divided in :

  • happypose
    • happypose
      • toolbox
      • pose_estimators
        • megapose
        • cosypose

2 important functionalities should be put in common in my opinion:

  • both megapose and cosypose contain very similar code for object 2D detection (a MaskRCNN interface)
  • cosypose contains a multiview pose estimator that is agnostic of the single-view pose estimator

My proposition (debatable):

  • happypose
    • happypose
      • toolbox
      • pose_estimators
        • megapose
        • cosypose
      • detectors
        • maskrcnn
        • cnos (to add)
      • multiview

With this approach, cosypose/megapose folder would contain only the pose estimation related code (as well as examples, evaluation, training etc.).

@MedericFourmy
Copy link
Collaborator Author

We could think about where to put depth refiners as well.

@nim65s
Copy link
Collaborator

nim65s commented Feb 21, 2024

I think this would be nice, but really breaking. So maybe we should get v1 first, maybe v1.1 after that, and then make this move for v2

@MedericFourmy
Copy link
Collaborator Author

For single-view pose estimation I'm not sure it would be that breaking. The high level interface to both single view pose estimtors is their respective cosypose PoseEstimator and megapose PoseEstimator. These classes would not change place or API, just some import paths to load the detector and depth refiner would change.
If there is code somewhere that directly imports the detector/depth-refiner then yes it's breaking for them.

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

No branches or pull requests

2 participants