-
Notifications
You must be signed in to change notification settings - Fork 10
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
Bring your own local model via UI #37
Comments
Users certainly should not need to edit any file. The only thing we can expect from them is to be able to select a file on disk. So, having an "import model" feature where the user can select a local file that contains the model zip file (containing the .pt files, labels .csv files, and model desccription json files) could be useful. We can require developers to generate the .csv and .json file and zip them up in a required folder structure. Maybe something like this:
The module would unzip the file into c:\Users\andra.MONAIAuto3DSeg (probably into a new subfolder, maybe unique name generated from hash of the .zip file) and the module would always retrieve models from this file as well. I'm not sure how hard we need to push developers on taking label definition seriously. On one hand, letting developers not use standard terminology has resulted in the mess we are in now with many projects: there are lots of mixups due to different training data sets and AI using different label values and names for the same thing and not being sure what exactly each ad-hoc name means. This certainly has to stop. On the other hand, if only MONAI Auto3DSeg does all the developer education and convincing work then developers may simply feel this as an unnecessary nuisance and will just hate us and fake some .csv files to satisfy requirements or just not work with us. How do you think we can make the .csv creation easier? I find it already really easy with Excel. However, maybe you mean that figuring out what standard term to use. Would documentation (tutorial on how and where to find codes) and examples for all the commonly used segment be sufficient? Adding a .csv file generator could make things even easier, but then that would be one more thing to maintain. |
It would probably be easiest to have a basic segment editor comparable widget that the user can utilize to create a segmentation, add segments, set names, and select terminology. The final segmentation (no actual segmentation needed) can then be used to export the terminology into the expected format. If a different terminology was used (like we did for SlicerHeart), it should be exported with the .csv file and separately loaded if needed. @lassoan Let me know what you think |
Add an option to directly add a local model (not publicly available via any URL) through the user interface without requiring the user to modify the .json file as not every user would be familiar with .json syntax.
It could be a separate widget ( model manager ) listing all currently provided models with their attributes.
Also, I found it difficult to modify the .csv files for correct segmentation terminology.
The text was updated successfully, but these errors were encountered: