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
The original model was distributed using scivision (which uses intake under the hood).
You can read about the various benefits and use-cases for scivision and intake, but when we came to loading the model the only difference was that instead of importing the package containing the model and importing the model as per normal, we could instead install the scivision package and then run scivision.load_pretrained_model(URL) where URL pointed to the original repository. (In fact this returns a PretrainedModel object which is a wrapper for the original model.) See here for an example.
I like what scivision have done, in a way. It's quite neat and nicely documented. But I also feel like it could be more of a hindrance than a help. In our case, there is (currently) one model in the catalogue that could feasibly be useful to us, so the marginal benefit of accessing it via scivision instead of resnet50-cefas is...nil? We then also have to put up with redundant (to us) functionality in the wrapper and we become locked into scivision's update cycle which might be slower than we would like.
Reintroducing intake
Intake looks like a really nice tool, but at the time of writing I don't feel like I want to invest much time in it; it appears to be in a state of flux where maintainers are not recommending using the old version (v1) but the new version (v2), which is a full-scale rewrite, is barely documented. I also worry a little about v1 issues remaining unfixed because maintainers are working on v2. See e.g. this issue.
So my preference would be to wait until v2 is more 'finished' before thinking about using it here or elsewhere. This kind of suits us (@metazool@albags) anyway since we have plenty else to focus on...
Reintroducing scivision
Despite what I said earlier I do feel it is reasonable to contribute this back to the scivision catalogue, primarily because it seems bad that others could be trying to use the original model out of the box only to find that they have to downgrade everything to very old versions of Python and PyTorch.
My proposal is that we wait a little to see if scivision is planning to make any changes based on the ongoing update to intake, and once we can see a roadmap decide if/when we want to contribute this version (and possibly any more models we work on) back to scivision.
The text was updated successfully, but these errors were encountered:
Context
The original model was distributed using scivision (which uses intake under the hood).
You can read about the various benefits and use-cases for scivision and intake, but when we came to loading the model the only difference was that instead of importing the package containing the model and importing the model as per normal, we could instead install the
scivision
package and then runscivision.load_pretrained_model(URL)
where URL pointed to the original repository. (In fact this returns aPretrainedModel
object which is a wrapper for the original model.) See here for an example.I like what scivision have done, in a way. It's quite neat and nicely documented. But I also feel like it could be more of a hindrance than a help. In our case, there is (currently) one model in the catalogue that could feasibly be useful to us, so the marginal benefit of accessing it via
scivision
instead ofresnet50-cefas
is...nil? We then also have to put up with redundant (to us) functionality in the wrapper and we become locked into scivision's update cycle which might be slower than we would like.Reintroducing intake
Intake looks like a really nice tool, but at the time of writing I don't feel like I want to invest much time in it; it appears to be in a state of flux where maintainers are not recommending using the old version (v1) but the new version (v2), which is a full-scale rewrite, is barely documented. I also worry a little about v1 issues remaining unfixed because maintainers are working on v2. See e.g. this issue.
So my preference would be to wait until v2 is more 'finished' before thinking about using it here or elsewhere. This kind of suits us (@metazool @albags) anyway since we have plenty else to focus on...
Reintroducing scivision
Despite what I said earlier I do feel it is reasonable to contribute this back to the scivision catalogue, primarily because it seems bad that others could be trying to use the original model out of the box only to find that they have to downgrade everything to very old versions of Python and PyTorch.
My proposal is that we wait a little to see if scivision is planning to make any changes based on the ongoing update to intake, and once we can see a roadmap decide if/when we want to contribute this version (and possibly any more models we work on) back to scivision.
The text was updated successfully, but these errors were encountered: