What is the difference between the “Crosshair” versus using “Slice Intersections”? They seem to be the same type thing, but they are two different objects so it is a bit confusing about which one to use.
There is the Crosshair toolbar where the default action for the QToolButton toggles the visibility of the Crosshair. However I see more recommendations for users to turn on Slice Intersections which is a menu option buried at the bottom of the menu in the Crosshair toolbar. There is also a checkbox in the Markups module for turning on Slice Intersections. So it seems that Slice Intersections is the preferred option, but is not the default action of the QToolButton in the Crosshair toolbar.
In my Slicer custom application I already make the modification to make Slice Intersection the default action for the QToolButton, but I still don’t quite understand the difference of when to use Crosshair vs Slice Intersections.
@pll_llq Good catch! This is the correct snippet now:
sliceDisplayNodes = slicer.util.getNodesByClass("vtkMRMLSliceDisplayNode")
for sliceDisplayNode in sliceDisplayNodes:
sliceDisplayNode.SetIntersectingSlicesVisibility(1)
To reflect on the actual topic, I have a hard time finding a usage for the crosshair too. It is a singleton, and so there is a single crosshair in the application, sort of like a “current point of interest” as I interpret it. The one thing I can think of where crosshair is more than slice intersections is that it is visible in 3D. Maybe we should add a checkbox for slice intersection visiblity in 3D and get rid of crosshairs altogether?
slice intersections show where other slices are located on a slice view
There’s no reason to assume that the slices intersect or are orthogonal. Or that there are only two other slices to display in a given slice view. It can be useful to show the current crosshair even when it doesn’t crosshair even when it doesn’t reflect the current slice location. E.g. use shift-mousemove to position the slices and crosshair pick a reference point in 3D. Then use the slider to scroll the slices and crosshair stays at reference point and doesn’t follow, which can be handy.
Is “Crosshair” then similar to my action of me dropping a control point of a Point List which represents a single point in space to mark a reference point and which I can click on to jump slice offsets to quickly get back to my reference point?
@pieper If you think crosshair usage and slice intersection usage are two distinct concepts, do you think these two things should be separated in the GUI? They are currently in the same QToolButton menu as part of the “Crosshair Selection” toolbar. Should their options be in the same toolbar, but in their own QToolButton (and own menu)? Or are they distinct enough to warrant separate ToolBars where you could hide one of these toolbars, yet still see the other?
I don’t have a strong position on this, I just wanted to point out that yes, they are different. I think they were just added on the same toolbar menu to save space and because they are somewhat similar. Now that there’s more functionality in the slice intersections maybe they should have a more independent place.
I sometimes follow a procedure a bit like that. But then if I’ve zoomed in on (say) Slice Y to one location, then then move (through Shift+mouse-move on the 3D view or a different Slice) the cross-hairs to a new location, I get frustrated that the point will often be outside of the current FoV for Slice Y. That means I either need to
zoom back out until I can identify the new location, pan to ~centre on the new location, and zoom back in (tedious, and typically resulting in a zoom that isn’t precisely the same as the original zoom); or
progressively pan to where I ‘think’ the new location roughly is (tedious if the new location is far outside the current FoV, so that many mouse drags are required, and I might not immediately head in quite the right direction).
So is there an existing functionality that I’m missing to centre the Slices and/or 3D view on either the current cross-hairs or the current intersection — either while they are being modified (instantaneously & automatically)† or afterwards (upon user request), without modifying the respective zoom levels?
—DIV
† In this case, the centring wouldn’t/couldn’t be implemented on the pane in which the mouse is being controlled.
