Run local Auto3DSeg model

[diazandr3s]

Run local Auto3DSeg model

[lassoan]

Thank you for the PR. This will be a useful feature but it would be good to discuss this before merging.

• If it is a debugging feature for developers then it should go into the "Advanced" section to not complicate the GUI with features that are irrelevant for users. If it is for making it easier for developers to create/package models then we should provide a widget where developers can specify model metadata (name, description, etc.).
• If it is for users, to make it easier to install models received via local folder or remote URL then we should add an import from local folder/custom URL feature and the the location should contain a .pt file and labels.csv file and the imported model should show up in the models list.

In general, I feel bad about making it easier to import a model without making it easy to specify model metadata and label description as well. Would it be too much to expect developers who spend hours creating a new model, spending minutes with properly specifying the absolute minimum (label value specification) and some basic metadata (name, description, modality, etc.)? Or your concern is that users don't know how to create the label.csv file? Then we should make it easier to look up codes. Or, until we develop a simple and well-liked solution for looking up codes, we could even consider not requiring specification of a code, just reuire label value + name.

[diazandr3s]

Thank you for the PR. This will be a useful feature but it would be good to discuss this before merging.

* If it is a debugging feature for developers then it should go into the "Advanced" section to not complicate the GUI with features that are irrelevant for users. If it is for making it easier for developers to create/package models then we should provide a widget where developers can specify model metadata (name, description, etc.).

* If it is for users, to make it easier to install models received via local folder or remote URL then we should add an import from local folder/custom URL feature and the the location should contain a .pt file and labels.csv file and the imported model should show up in the models list.

In general, I feel bad about making it easier to import a model without making it easy to specify model metadata and label description as well. Would it be too much to expect developers who spend hours creating a new model, spending minutes with properly specifying the absolute minimum (label value specification) and some basic metadata (name, description, modality, etc.)? Or your concern is that users don't know how to create the label.csv file? Then we should make it easier to look up codes. Or, until we develop a simple and well-liked solution for looking up codes, we could even consider not requiring specification of a code, just reuire label value + name.

Many thanks for your comments, @lassoan. They are helpful.

I thought this feature to be a sort of debugging tool for quickly analyzing the results of a local model before it is public. I fully agree we shouldn't complicate the GUI with features that are irrelevant to users. Let's add this in the Advanced section.

Regarding this,

Or your concern is that users don't know how to create the label.csv file? Then we should make it easier to look up codes.

Yes, I think we should facilitate this. I'd like to learn more about it to also integrate them in MONAI Label.

Happy to further discuss this over a call.

[lassoan]

What do you think about selecting not a .pt file but a folder that can contain a model.pt and labels.csv file? This could be used to fully test a model before it is published.

Possible implementation: In the "Advanced" section add a folder selector (or folder list selector qSlicerDirectoryListView) and these local additional model(s) show up in the model selector. If the folder(s) contain model.pt and labels.csv file then an entry as added to the model list. The model name could be set from the folder name; or if a metadata.json file is present in the folder (with the same content as an item in the Models.json file) then that could be used to populate the model selector (thereby giving an opportunity to testing the json file content, too).

Or your concern is that users don't know how to create the label.csv file? Then we should make it easier to look up codes.

When you create a segmentation in Slicer and add a segment and double-click on the small colored rectangle next to the segment name then you get the terminology selector. We could build this selector into the Colors module in Slicer to edit color map files (like labels.csv). I've added a feature request for this in Slicer, feel free to comment there if you have any suggestions. Similar editors could be implemented as web apps (I think there is already some javascript terminology selectors that could be used as a basis) to make it even easier to access.

[diazandr3s]

Hi @lassoan,

Thanks again for the comments. I think choosing a folder containing both model.pt and label.csv in the Advanced section is a better way to have this feature. Let me create a proposal,

Best,