Page MenuHomePhabricator

Create crosshair for single render windows
Closed, ResolvedPublic


Currently the crosshair is realized by the intersection of the three view planes. This only works in the StdMultiWidget, where all three 2D-views always show the three anatomical (orthogonal) planes.
Using the custom multi widget, it may happen that the three view planes are parallel and therefore no intersection is visible.
The problem is already mentioned in T22876.

Furthermore, the crosshair is based on the GeometryPlanes computed by the different views. If we want to have individual render windows, we might not provide all three views of a loaded image and therefore cannot retrieve the geometry plane of three different views.

The questions remains: What is the purpose of a crosshair / position pointer for a single render window?

Event Timeline

kalali raised the priority of this task from Wishlist to Needs Triage.Dec 6 2017, 1:24 PM
kislinsk triaged this task as Wishlist priority.Feb 8 2018, 9:24 PM

Using the new synchronization and display action event broadcast class, the SetCrosshair-function (invoking a DisplaySetCrosshairEvent) could be used to set a render specific crosshair.
In the render window manager a point set was used for creating a crosshair (see T22876). We will stick to the point set approach.

kalali raised the priority of this task from Wishlist to Normal.

Each QmitkRenderWindowWidget now comes with its own crosshair (as a pointset) that can be moved via the mouse interactions (either synchronized or non synchronized).

The crosshair currently does not update the status bar text (to show the pixel value and selected position).
Since the helper plane widgets were removed, the image slice navigator is currently disabled. However, is the 'GetSelectedPosition' of the multi widget editor usable?

Updating the status bar was a task of the DisplayActionEventBroadcast-class ('DisplayInteractor' for the StdMultiWidget). The UpdateStatusbar-function is now implemented. However, we should think about moving this implementation to another place. It is not really the job of any interaction class.

see T25105 for "moving the UpdateStatusbar-function

The crosshair is created for each render window widget. However, creating a render window widget and adding a point set to the data storage will open the stdmultiwidget, if the custommultiwidget has not been fully loaded. This happens if the custom multi widget is newly opened with a single render window widget.
So either the custom multi widget has to be opened / started without a render window widget or the point sets have to be added to each render window after the custom multi widget has been fully loaded.

This is mainly due to the fact that adding a node to the data storage invokes opening a render window editor, which is per default the stdmultiwidgeteditor.

It is reasonable to start the custom multi widget with (at least) a single render window widget. Some plugins assume an active render window to be available at any time.
It is also reasonable to not show a crosshair if no image is loaded inside a render window.
So our approach is to add a crosshair-pointset to a specific render window at that moment an image is added to this render window.
We still have to decide if this is the responsibility of the custom multi widget (editor), the render window (widget) or the render window manager (see T22876).

T25602 changed the render window manager to be a data storage inspector. Therefore data nodes don't have to be added or removed by the user but the render window manager will always provide a filtered view on the data storage (filtered by the currently active base renderer).

Question: When will the crosshair be defined?

Custom multi widget editor knows when it is being (de-)activated and will (de-)activate (add / remove) the crosshair point set nodes accordingly (similar to the StdMultiWidget, where the planes where added or removed to or from the data storage).