Combine with T24356 (esp. T24368).

OK. But we definetly should talk about it before it is approached.

@kalali: Sharp eyes and good work. As far as I can see this is a proper solution to fix a state a had not covered in my implementation. The handling of invalid timepoints is still okay. As the documentation only guaranties that negative invalids will be 0. For all others there are no garanties and developers use GetTimeBounds() to check wether they request legal time points or not.

Pushed new branch T26269-ChangeSelectionInStatisticsPlugin.

Pushed new branch T26632-EnsureFileSuffixForCalibratedTool.

I think the problem is here: https://phabricator.mitk.org/source/mitk/browse/master/Modules/Core/src/DataManagement/mitkArbitraryTimeGeometry.cpp$124
The m_MaximumTimePoints for the 3D+t-Heart image is [103, 160, 160]. The last timePoint argument is 160. So in the first iteration if (timePoint < *pos) will be false. Next two iterations it will be false as well since 160 is not less than 160. This will lead to result being 0 at the end of the function.
Normally the m_MaximumTimePoints for another time-image is something like [41, 46, 51] and the timePoint argument will be 46 for the last timestep.
This could be solved by using something like this:

mitk::TimeStepType mitk::ArbitraryTimeGeometry::TimePointToTimeStep(TimePointType timePoint) const
{
  mitk::TimeStepType result = 0;

Pushed new branch T26635-RenderToolsLoadedFromToolStorageFile.

Solved when T26269 is solved.

Pushed new branch T26634-RenderLoadedIGTTool.

See T24766.
I also experienced the two-step when debugging but using only console-output this does not happen with other time-data than 3D+t-Heart

The issue with the missing file extension only occurs on Linux.

This does not happen with the new mxn multi widget. Maybe connected to the render windows being synchronized / plane nodes when using the StdMultiWidget?

Please talk to @kraeuter to as she is currently working on T26269

The new implementation of the image statistics plugin offers a pulldown menu for image and mask image. This avoids the inconsistent data selection.

it actually does already

Compared ManualEditToolTip functions of IGTNavigationToolManager and IGTNavigationToolCalibration plugin which works correctly. In former, the storage is disconnected before editing the tool and when a new tracking connection is made the edited tool tip and orientation is lost. But in calibration plugin the editing of tool is done while tracking device is connected, so the information is preserved.
@eisenman @franza Can we remove the condition that the tracker has to disconnected before editing the tool or is there another work around for this.

T26609-2018.04.beta.CT-Registration-Demo is based on a old 2018.04.beta version, CT registration is working.

Pushed new branch T26609-2018.04.beta.CT-Registration-Demo.

T26609-2019-08-USNavigationFix is based on 2019-05 MITK master, US Navigation is working, but CT registration is buggy.

Pushed new branch T26609-2019-08-USNavigationFix.

Level window widget has been added to both multi widget editors, presets work.
Using the context-menu of the level window slider the user can select the node he or she wants to modify. Using the multi-node selection approach from T25804 requires the selected-property to be set by the render window manager.
However, the multi-node-selection approach is included as the data manager is currently always available.

Pushed new branch T26495-Enable-level-window-slider-and-presets.

I came across this as I re-added the level window slider to the MxNMultiWidget (we didn't include this before as we used the PACS mode inside the MxNMultiWidget - which allows to change the level window via mouse moving). Now our user wants to use the level-window-presets available from the context menu of the level window slider.

In T25804#185436, @kalali wrote:

This would be necessary if we want to use the render window manager with the mxnmultiwidget and the mentioned task (T25483).

This would be necessary if we want to use the render window manager with the mxnmultiwidget and the mentioned task (T25483).

For test purposes this has been solved for the segmentation module / plugin in 450d57dd of T24215.

Also when changing the interaction mode (PACS <-> MITK) while the segmentation tool (e.g. Add) is active, the changed interaction mode will overwrite the segmentation interaction and the render window changes again while drawing the segmentation.

There seems to be a problem with the mitkDisplayActionEventBroadcast-class in general. Some classes have legacy code that disables the default display interactor to load a scenario-specific state machine and config file (see e.g. https://phabricator.mitk.org/source/mitk/browse/master/Modules/Segmentation/Interactions/mitkTool.cpp$121).
This is done in other classes. The problem is that the function does not reset the display action event broadcast instance but only display interactor instances.