I think it is trying to warn you that you are requesting to use GPU (cpu=False), but you have no CUDA supported GPU so it is falling back on the CPU. Since the warning says it may take an hour for full resolution results on CPU are you actually sure you want to go with that method?
It looks like you would have to modify the following code:
Are you creating a script to run the TotalSegmentor on several volumes? Have you been able to do this? If so, I would be very interested in knowing how you have done this.
Hi again @jamesobutler
Do you know if there is a way to someone automatically trigger selection of the second GUI button option (slow option) without having to adjust the TotalSegmentator plugin code itself?
Not that I know of. Your best bet is to modify that SlicerTotalSegmentator code where I linked previously to comment out the pop-up display. Otherwise running on a system with CUDA support would also avoid the pop-up.
We should modify the logic code to not show any popup (or at least have an option to suppress). By the way, if you run Slicer with --testing argument then I think all popups are bypassed.
Thanks @lassoan and @jamesobutler
I modified my local version of the code to commend out everything under “if not fast and not cuda.” and replacing it with a print statement “using slow mode”.
This works well.
@lassoan
Maybe the section can be removed altogether from the TotalSegmentator plugin?
Since for the GUI the user can already designate whether to use Fast mode or not.
I guess the original point of the pop up was to warn users that using fast mode without cuda can take a long time. But the “~50 minutes” is also a big overestimate in some cases.
So my suggestion would be to just remove this section altogether. Users can then select “fast” mode or not in the GUI or the code arguments and can test themselves whether fast mode is necessary.
A way to do it could be to put the checkbox ask before the call to process in the function onApplyButton . That way for the user nothing changes but we can call the process function without the need for human intervention
I tried to make a pull request on the github with the above changes
I also noticed I never replied to the cpu=false point (good question).
I want to set cpu=false because otherwise it forces cpu use.
As far as I understand, if I set cpu=false, it should then work with gpu if cuda is enabled, and if not, still resort to cpu.
The current code is the result of lots of feedback and troubleshooting on computers on thousands of users. All those checks and warnings are guardrails for users to prevent them from reporting that “Slicer crashed” (it actually just hangs for a long time, while the computation is in progress). So, simply removing these checks is not the best solution.
Adding a silent option (enabled by default, disabled when the module widget calls it) to skip any GUI interaction and just do what is specified in the input arguments would be a very simple change. It would be great if you could implement this, test that it works for you, and send a pull request.
Current location of checking the parameters and displaying of the popups is incorrect: all GUI interactions belong to the module widget and not to the logic. If you can implement this change so that it all works for you but the current behavior via the GUI does not change then that would be even better. maybe instead of a popup, a warning icon should appear next to the “Apply” button when runtime is likely to be excessive.
If you have any suggestion for changing wording of messages then please send a pull request. I also experienced that that full-resolution segmentation on CPU can run on a 20-core workstation with 64GB RAM within a few minutes, but on an i7 laptop with 16GB RAM typical runtime is around 40 minutes. Maybe some of this information could be added to popup messages and documentation.
Also note that we are releasing a new extension tomorrow: MONAIAuto3DSeg. It has similar models (low-res/high-res with similar hardware requirements) like TotalSegmentator, but better in many sense: does not contain only a few models, but over 30; not just healthy anatomy, but various abnormalities; not just CT, but also MRI (and some private models successfully used on ultrasound, too); it can accept not just a single input image but multiple images; it can run in the background and segmentation can be interrupted anytime; has less Python package dependencies and installs more cleanly and can be trained faster than nn-UNet, etc. I would recommend to check it out.
I am currently running on i7 laptop with 16GB RAM but I just realized that maybe it is running much faster because I have small crop volumes of the shoulder joint instead of a whole body.
I will try what you suggested.
If you can implement this change so that it all works for you but the current behavior via the GUI does not change then that would be even better. maybe instead of a popup, a warning icon should appear next to the “Apply” button when runtime is likely to be excessive.
I was also thinking this could be a good solution to keep the warning.
I will try to make the adjustments you proposed.
Also note that we are releasing a new extension tomorrow: MONAIAuto3DSeg
This is great, thank you! Excited to try it.
I am looking into the code and have an idea how to do this.
I see the widget checks if buttons are clicked/boxes are selected in lines 104-116 of def setup, and then runs some functions if they are (e.g. for
I want to add a line that checks if the Fast box is toggled and then run a function called onSetSlow that incorporated the GUI warnings that we discussed.
I see that I can use:
self.ui.fastCheckBox.connect(‘toggled(bool)’,self.myFunction) to run a function if the Fast box is toggled
What syntax would I need to check if the box is NOT toggled?
To run the warning if fast mode is not selected?
I would recommend to add one more argument to the process method: interactive (set to False by default). If interactive=True then the method works the same way as now (the widget will call the method this way). If interactive=False then no popups are displayed but the method does what the fast and cpu flags dictate (you will call the mwthod this way when doing batch processing).