@kalali: Sharp eyes and good work. As far as I can see this is a proper solution to fix a state I 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 should use GetTimeBounds() to check wether they request legal time points or not.

Pushed new branch T26269-ChangeSelectionInStatisticsPlugin.

ToDos

• implement final caseID socketbased
• port encryptData to socketbased
• distinguish between uploading sites (such as CSI, E010, etc.)
• when decrypting, differentiate between files and string
• include IV of encrypted file
• include client PublicKey
• can formData be transported by websockets
  • compile needed socket.emit statement. emit supports Buffer

First initialize a TLS based websocket connection between browser and server. In addition encrypt the files using AES-GCM 256. Key to encrypt files is computed using ECDH P-384. Private/Public Key for ECDH is generated independently from the TLS secured websocket connection.

Koa.js is the way to go in this case

First initialize a TLS based websocket connection between browser and server. In addition encrypt the files using AES-GCM 256. Key to encrypt files is computed using ECDH P-384. Private/Public Key for ECDH is generated independently from the TLS secured websocket connection.

cannot be accomplished using cornerstone, since errors are thrown if non-dicom filesize is below "proper" DICOM file. Therefore we implemented our own routine to check if incoming filesize is below 132 bits, otherwise check if bits from 128 to 132 represent "DICM".

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.

It has been resolved in branch T26630-AccessAugmParams

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?

Is this still valid? I looked at it but couldn't reproduce the bug.
If you can reproduce it, could you try to reproduce it with Pic2DplusT and MITK-Data/3D+t-ITKIO-TestData as well?

I created such a segmentation on the 3D+t-heart dataset and stored the segmentation as *.nrrd. The I loaded the *.nrrd-segmentation again and I now I can only see the segmentation on the first timestep.
Important: The timesteps of the *.nrrd-segmentation are now from 0 - 3 and with a duration of 1ms. The original 3D+t-Heart was [0,103] [103,160] [160, 160]. This was also true for the original segmentation. If I store the 3D+t-Heart image as *.nrrd and reopen it again the original timesteps are preserved.

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

I also tried it with MITK-Data/3D+t-ITKIO-TestData and everything works fine (segmentation and time-slider). However, a difference between all these time-images and the 3D+t-Heart// image is, that the Heart-image does not actually have a third timepoint, as the third timepoint is of length 0ms.
So maybe there is a problem with the matching of time points and the segmentation is displayed for the last time point, as the lats time point is actually non-existent and wraps around to the time point 0.

I just tried this and I can reproduce it with MITK-Data/3D+t-Heart. But when I used Pic2DplusT the segmentation was only created on a single timestep.
Additionally, when I clicked on the arrows of the time-slider of the image navigation plugin the time slider sometimes wraps around the last time step and returns to timestep 0. This was already mentioned here T25030. However, this does not happen If I use the Pic2DplusT image so maybe the 3D+t-Heart image is corrupt?

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

Pushed new branch T26628-Ivim.

it actually does already

Pushed new branch T26602-DipyRecon.

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.

The modified render window has been added and can be used by the StdMultiWidget and the MxNMulwiWidget (see T24215).
This is used here and a new entry for the render window menu has been added.