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
Hi @wyli
Here is a gist of the code I was showing today.
What I think is that we can write a middle layer (something more general as is written for Breast Density here) which can take any model from the model zoo. This class will take the model name and download the bundle on the first instantiation. After that using get functions, users can pull appropriate pre and post-processing pipelines and trainers, data loaders etc. If something is not implemented for a particular bundle we can throw messages that "it is not implemented" for that bundle.
Pros:
For using this, we will be able to leverage our already existing config parser and need to write a very thin layer between the model zoo and the Pythonic interface)
Cons:
We need to standardize our configuration files, like preprocessing is not "pre_processing" and similar terminology usage. We can create a cheat sheet for the model zoo vocabulary which should be followed for creating new bundle.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi @wyli
Here is a gist of the code I was showing today.
What I think is that we can write a middle layer (something more general as is written for Breast Density here) which can take any model from the model zoo. This class will take the model name and download the bundle on the first instantiation. After that using get functions, users can pull appropriate pre and post-processing pipelines and trainers, data loaders etc. If something is not implemented for a particular bundle we can throw messages that "it is not implemented" for that bundle.
Pros:
For using this, we will be able to leverage our already existing config parser and need to write a very thin layer between the model zoo and the Pythonic interface)
Cons:
We need to standardize our configuration files, like preprocessing is not "pre_processing" and similar terminology usage. We can create a cheat sheet for the model zoo vocabulary which should be followed for creating new bundle.
Beta Was this translation helpful? Give feedback.
All reactions