During 2016 Summer Slicer Week we worked on a project using histology to build an atlas. @pieper gave me some useful tips for this.
Here’s a video Tina asked me to upload:
Sonia and Steve said this could be interesting for @fedorov and the
Slicer Pathology extension. More recently, Sonia was in Paris and asked me about the code for the widget. I told her I hadn’t shared it because it was not clean, not integrated and has a lot of limitations. She said I should share it as it is, since someone else might want to contribute to improve it and maybe integrate it into Slicer at some point. I’ve worked a bit in order to integrate the widget into
Some of the many caveats:
- Only 2D images are supported
- Only RGB images supported (probably very easy to make it work for grayscale as well)
- Currently uses the background image of the red slice
Here’s the code: https://github.com/fepegar/Slicer-DataProbe-Histology/blob/master/DataProbe.py
I tipically use the widget for images like this (that’s a downsampled version, as histology images are usually very large).
Hi Fernando, thanks! This utility will be very useful also for my astronomical use cases. I guess the best way to allow extensions to use it, it is to clean and integrate the modifications in the core. The only problem will be to understand if it is useful also for the others and how to integrate it without making the interface too complicated and crowded (e.g., we want it only for the red slice, or also for the other ones? or a menu for swtiching?).
Probably it’s better to put this into a docking widget (similarly to the Python interactor). The widget can be popped out, moved to another screen, etc. or can be snapped to a side of the screen or below/above any other docking widget. See an example here: https://github.com/SlicerRt/SlicerDebuggingTools/blob/master/NodeInfo/NodeInfo.py#L224-L257
I would not put anything into already too crowded and too big Data probe widget.
Seems like this could be a generalization of the Slice Intersections
concept, but showing the borders of another slice view as an overlay on an
slice view that has the same orientation and offset. That would give a lot
of flexibility since it would handle arbitrary orientations and would also
allow panning and zooming of either slice (or showing multiple slice views
at different zoom levels all with their outlines visible in the ones that
are more zoomed out (or multiple insets in the same large image).
That’s a great idea. We had problems in the past with intersection of nearly-parallel slices anyway (intersection lines showed up in unpredictable locations). If we detect that slices are parallel, we could show intersection with a ribbon around the slice boundary.
Good ideas! Something like this? (This image is photoshopped)
Yes. It would be useful to improve slice intersection display also for thick slice reformatting (to show the slice thickness). vtkMRMLModelSliceDisplayableManager should be tuned to display slice intersections differently than regular model nodes (at least when the slice model is nearly parallel to the current slice and when slices are thick). Mantis issue describing incorrect slice intersection display for nearly-parallel slices: https://www.na-mic.org/Mantis/view.php?id=3360