The Grow from Seeds effect in the Segment Editor module has a couple of quirky points.
First is one small matter: it only considers seeds for Segments that are toggled visible (in the current Segmentation). Actually this is not a bad thing. The problem for me is that I didn’t see it mentioned in the GUI. Frankly speaking, I didn’t notice it at first in the documentation for the Segment Editor module either, although eventually I see that it does say “Only visible segments are used by this effect.”. Perhaps just one word could be inserted in the GUI to address this:
“Minimum two segments are required”
could be amended to
“Minimum two visible segments are required”.
Secondly, it seems that there is a kind of ‘dead end’ created when the preview Volume is deleted through the Data module.
Eventually I discovered the following workflow:
(a) Paint seeds in many segments. (b) Toggle visibility of some relevant segments off.
Set up Grow from Seeds effect by clicking Initialize. This produces ‘wrong’ results in the preview Volume.
Click Cancel in the Grow from Seeds effect’s panel.
Toggle visibility of all relevant segments on.
Set up Grow from Seeds effect anew by clicking Initialize again. This produces ‘right’ results.
But there is a problem here:
[as above]
[as above]
(a) Delete the preview Volume in the Subject heirarchy tab of the Data module. (b) The Cancel button in the Grow from Seeds effect’s panel is disabled.
[as above]
Set up Grow from Seeds effect anew by clicking Initialize again. This produces the same ‘wrong’ results as before, because Cancel was not clicked.
We host the Slicer documentation on github and welcome any suggestions there. Click on the “Edit on github” button on the top-right corner to edit the file and create a pull request from the suggested changes automatically.
It was obvious for the developers that the user must not delete the preview volume, but maybe not for all users. If you think that adding a note to the documentation would help then please add it. However, probably it would be better to make the effect more resilient. You can add submit a feature request to the issue tracker about this and someone will get to it eventually (you could volunteer, too).
This is the intended, good, and useful behavior. Always using all segments for “Grow from seeds” would seriously limit what you can do with it. We already documented the behavior in that short sentence and rely on this in several tutorials, but maybe we should further explain it in the documentation with examples?
I had a go, but accidentally clicked the Enter button before I’d finished describing the change (or verifying what I’d actually changed).
I couldn’t see how to edit a Pull Request, but maybe it’s alright.
For me deleting the preview volume (after I discovered its existence) seemed to be the most conclusive course of action, because (in my mind) once it was gone, there couldn’t be any trace of the previous initialisation remaining. Compared with an (in my mind) ‘anonymous’ Cancel button for which I wasn’t too sure what precisely was being “cancelled”.
I agree with you that in this matter changing the documentation would be more of a stopgap, and a better solution would be to make the software more robust. For that I can suggest two alternative options:
Deleting the preview volume automatically invokes all of the actions that would have been invoked by clicking Cancel. The Cancel button becomes disabled/inactive upon completion. (Preferred)
Deleting the preview volume does not have any further consequences. The Cancel button remains enabled/active upon completion. (Less preferred)
Now that I understand what’s happening I can agree that it is indeed useful behaviour — at least when irrelevant segments are toggled off (although I had toggled off some relevant segments, which I tried to indicate in the enumerated workflows above).
It may be just me that missed the short sentence in the primary documentation on the first reading (but noticed it eventually). I’ll take your word that it’s covered in the tutorials, which I either (for some) went through in the past and forgot that detail of, or else (for some others) did not go through.
Perhaps with the small extra cue in the GUI (as suggested above) there might not be a need for further changes in the documentation, as the GUI provides the most ‘immediate’ guidance — unless several other users have also stumbled as I did.