search

lassoan / SlicerMONAIAuto3DSeg

Extension for 3D Slicer for running MONAI Auto3DSeg models
MIT License
67 stars 10 forks source link

Bring your own local model via UI #37

Open che85 opened 8 months ago

che85 commented 8 months ago

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.

lassoan commented 8 months ago

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:

Models.json
mitralvalve-v1.0.0\model.pt
mitralvalve-v1.0.0\labels.csv
hlhs-v1.0.0\model.pt
hlhs-v1.0.0\labels.csv

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.

che85 commented 8 months ago

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