I’ve been a regular user of 3D Slicer for a few years now. In particular, I make use of the Markups Module a fair amount for image fiducial placement. We have protocols in which upwards of 250 individual markup points are placed (for evaluating registration quality and for visualizing intracranial electrode locations).
I’ve had the opportunity now to train ~50 students on how to use the Markups module and a few clinicians. My proposal below relates to observations when teaching new users how to use the module and questions/comments that have come up.
I would like to ask about the possibility at some point of offering a few features in the Markups module that could really enhance productivity and usability:
A Markup undo button (in case a markup is placed or moved accidentally).
The ability to move/copy multiple rows in the Markups module to a different MarkupsFiducial (currently I’ve only managed to do this for one fiducial at a time).
Happy to expand on our workflow and use cases if necessary. I’ll also be attending Slicer Project Week in London, Ontario, Canada in a few weeks in case there is time to discuss then (see here for details: https://github.com/NA-MIC/ProjectWeek/tree/master/PW29_2018_London_Canada). I will likely be offering our intro to slicer (i.e. markups) tutorial during that time should there be enough interest.
Those sound like great ideas - we don’t have anyone actively working on the Markups right now, but @lassoan mentioned he is planning to dive into at least the widget implementation and maybe he’ll also do some other features while he’s at it (I don’t know his full plans). I think he’ll be at the London Project Week.
Sounds great. I’ll get in touch with @lassoan if he’s in London.
Do you have a mechanism for submitting feature requests other than this forum? e.g. on Github?
Yes, markup module can use some love. I have couple other suggestions as well:
Once a fiducial is placed, we need the ability to restrict its movement in 3D viewer to single planes for more controlled placement. For example, a stroke moves it incrementally along Anterior (and shift + A along Posterior), r moves it along Right (and shift + R along left) so forth.
The issue of scaling of 3D glyph size with respect to the slice view is still not resolved (at least in the resolutions that I am working on -tens of microns). I have to constantly move the slider back and forth to make it visible in the slice view and then not gigantic in the 3D view. I actually don’t understand the logic behind 3D glyph getting bigger as I zoom into a specimen. It is a point, why doesn’t render at a fix scale (say twice the voxel size) regardless of the field of view?
Great suggestions, @muratmaga. I’ve noticed the issue with glyph sizing as well.
Fyi, I submitted the two requests above late last week and the copy/paste functionality has already been implemented (pending review) and the undo feature may involve mostly reviving existing code. Thanks @lassoan for the rapid response!
The Markups Module is one of the key features in Slicer for which I have found no equivalent in other open source image analysis/visualization packages. I have several other (more minor) enhancements I would be happy to suggest if there are plans to dedicate resources to improving this module.
The glyph is in the 3D scene, rendered as a 3D actor, therefore by its size is defined in the 3D scene and not in screen size or pixel size. If we simply rendered it as a 2D actor then it would lead to many issues - it would always visible (even if it should not, e.g., because some foreground object occluded it), its size would not provide hint about its distance from camera, etc.
It could be possible to have a hybrid solution - use 2D actor but try to figure out when it should be hidden; or use a 3D actor but try to normalize its size - but it is not easy to implement, has not been required for any funded projects, and no community member volunteered so far to address this.
I would like to load a list with fiducial names (bony landmarks) in order to avoid that the rater has to input all the names by himself. Is this possible somhow?
Then the rater could select the already named fiducial and pick the position on the segmented surface or the slice view.
And would it be possible, that the fiducial sticks to the segemented surface if it’s moved in 3D:
Here is an example video: https://streamable.com/kc47h
You can do that. Generate your blank landmark labels using the Markup tool, save that file (.fcsv), and reload it each time you need to annotated a new specimen.
The challenge with this approach is that modifying a fiducial position easily and effectively is not straightforward, at least with the current tools. More so, if you are doing it in 3D renderer. It is almost easier to do it from scratch, and copy and paste the landmark label from a text file.
A slightly better approach would be do a full set of landmarks on one of your specimens, and save it as a reference. Then, register every sample rigidly to that one, and then load the reference landmarks. That way at least the landmark set will be in roughly approximate positions. However, if you have large size differences it would not work.
@lassoan There is a good chance we may be able take on these issues, with guidance from you, Steve and other experts. Our timeline and commitment should be more clear in the next couple weeks.
Yes, that is exactly the problem. I could create a list with the desired names and the fiducial at the origin (0,0,0), but then it’s not possible to reposition the fiducial to the surface of the object, especially if the object is far away from the origin.
So IMO it would be useful if an existing fiducial could be repositioned easily including the stick-to-surface feature: https://streamable.com/kc47h
I think this would introduce bias to the rating. The rater should determine the postion by himself without seeing a rough approximation.
Stick to surface feature would be definitely useful. However, that will only work with 3D models. Volume rendering technique does not provide a surface to stick the fiducials on.
Stick to surface will be probably implemented using VTK picker classes, which can find 3D position of a point visible in a view at a chosen position. These picker classes already work with most actor types, such as polydata models and volumes. There is no limitation here.
You are right that VTK locator classes require mesh inputs. However, locators are not needed (and not well suited) for 3D position computations for “stick to surface” feature. If for some reason you needed locators for 3D volumes anyway, then you could generate the necessary iso-surface very quickly.
It was great meeting many of you at the Slicer Project Week last week in London, Canada!
I wanted to summarize some of the discussions I’ve had with @lassoan in the interim, and also review his implementation of the enhancements to date.
Andras has implemented the copy and paste feature on nightly (20180725) such that multiple (not necessarily contiguous) rows can be selected. Then using the new Copy and Paste icons, the selected rows can be pasted to a new list or spreadsheet. Hotkeys for copy and paste also work!
One open issue to be resolved is that the old right click Copy functionality still only supports a single row. I spoke earlier with Andras, and the most intuitive solution here is probably just to make this functionality the same as with the icons/hotkeys.
