Pushed new branch T24358-Remove-QmitkMouseModeSwitcher.

A new class, the QmitkInteractionSchemeToolBar has already been introduced in 9ab09bff137b. This class is used as a replacement for the QmitkMouseModeSwitcher. It it a simplified version which does not observe the mouse mode switcher / interaction scheme switcher. There is no observer tag and no block-functionality.
Additionally, the tool bar is adjusted to match the new InteractionSchemeSwitcher (see T24357): There is no difference anymore between a mouse mode and an interaction scheme (see T24368).
The new toolbar is used for the mxnmulwiwidgeteditor and is currently tested with the stdmultiwidgeteditor (see 732f754ad203).

Has been solved on top of T26476.

Pushed new branch T24368-Adjust-display-config-files.

I decided to go for having an own complete .xml-file for each mode, so I added the full definition for the different PACS modes.
The reason is that we want to have a consistent interaction scheme-handling which means either having full definition for both MITK and PACS modes or having base- and additional definition (like the original PACS modes). But changing the MITK configuration files to the base- and extra-mode variant requires event_variants to be empty in order to disable certain mouse events. Additionally any implementation needs to do two calls, one for setting the base-mode and one for adding the extra mode to make sure the correct base-mode is always set (e.g. switching from MITK to PACS). This was undesirable.

encryption works as expected

I'm not sure if this is a valid issue.
I can reproduce the observable result if I don't disable the segmentation tool. I'm still in the drawing mode if the segmentation tool is enabled. If I change the display interaction mode now (by enabling Crosshair rotation (or any other mode - also No crosshair rotation), the MITK interaction scheme is enabled and both interactions happen at the same time (navigating and drawing).
Disabling and re-enabling the tool will again overwrite the navigation interaction and allow to draw the segmentation without any problems.

I can not reproduce this.
After having deselected the Region Growing tool, I can use the left mouse button and move the mouse to scroll through the slices. "Normal" scrolling (does this mean scrolling using the mouse wheel?) does not work. Notice that you can always scroll by pressing the middle mouse and moving the mouse (regardless of the selected PACS mode).
However, in T26486 I changed the PACS mode such that you can always scroll through the slices using the mouse wheel (regardless of the selected PACS mode). The special PACS scroll mode still works for fast scrolling (left mouse button and mouse moving).

Has been solved on top of T26476.

Pushed new branch T24635-Prevent-infinite-scroll-loop.

Pushed new branch T26486-PACS-mouse-mode-with-mouse-wheel-scrolling.

Pushed new branch T26642-Restore-original-interactions.

Combine with T24356 (esp. T24368).

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

1. encoding File/Blob object to ArrayBuffer (needed as input for AES encryption) crashes browser (tested on Chrome) if file is bigger 1GB:
   • check chunking

@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.