Thanks Ralf!

Describe problem has the same root then T26953. But I think for this task here we can have a work around, so that Hanno does not need to wait until the DICOM Seg thing is fixed.

We see and feel you. Considering the circumstances that Ralf mentioned (it's basically an ITK issue/contribution) I would anyway go for a Won't Fix here on our MITK side for now, until ITK provides the functionalities for such data types. Okay? :)

Discussed: Proposal is fine, we should do it this way.

As it is a really nice user-friendly feature, we have a high interest in getting TotalSegmenter integrated soon into MITK.

Created an example in this pull request: https://github.com/MITK/MITK/pull/271

We talked about this task in our meeting today and concluded that we will migrate the DataStorageComboBox in our code to the SingleSelectionWidget and even deprecate the DataStorageComboBox.

Pushed new branch to rMITK MITK: feature/T29297-Use-selection-widgets-in-render-window-utility.

Somehow related:

• T24319: Provide filtering techniques for interaction events
• T24274: Globally accesible synchronization handler

Related: T13465: Two 3D RenderWindows at the same time interfere with each other.

I may have found the problem but unfortunately for me that looks like it cannot be easily fixed:
During PlaneGeometryDataVtkMapper3D::ProcessNode, when the plane node to be rendered is processed (called from PlaneGeometryDataVtkMapper3D::GenerateDataForRenderer), imageMapper->Update(planeRenderer) is called. Here the imageMapper is the 2D mapper from the plane node.
Inside ImageVtkMapper2D::Update the mapper is updated by calling ImageVtkMapper2D::GenerateDataForRenderer. This in turn leads to the following line: const PlaneGeometry *worldGeometry = renderer->GetCurrentWorldPlaneGeometry(). I think this is problematic since here the current world plane geometry is used, which is the sliced geometry from the base renderer. However, for the 3D render window the sliced geometry is still either the axial, sagittal or coronal plane. It doesn't matter if we created three different planes from the world time geometry for the base renderer, the world plane geomertry will always be a specific sliced geometry.
Since these steps are performed for all three plane nodes to be rendered, all three plane nodes render the same world plane geometry.

It seems as if there is a general problem with the current crosshair: The crosshair manager provides three planes / plane geometries for each render window such that changing the view direction / anatomical plane will just switch to the corresponding geometry and render the information based on that geometry.
Having done some test with the visiblity of the planes, rendering inside the StdMultiWidget shows that all three planes (axial, sagittal, coronal) of a render window show the same image information / anatomical plane. Changing the view diretion inside the render window will change the anatomical plane, but then all three planes show the same image information of the newly selected anatomical plane.

I managed to fix the rendering of the 3D data even more and now the image information / pixel are shown.
But now the data seems to be inverted on some planes such that the three 2D planes do not match and form a 3D object.

So I fixed part of it by setting a PlaneGeometryDataVtkMapper3D explicitly as done in {D759} for the 2D mapper. Then I was able to immediately set a valid data storage and the crash is fixed.
The three planes are rendered inside the 3D render window but only the frame is visible - no image information / pixel is shown.

So it seems as if the PlaneGeometryDataVtkMapper3D is newly created (automatically) when a render window is changed to a 3D render window (mapper changed to Standard3D).
In that case, the m_DataStorage is empty and the following functions crash (e.g. mitk::DataStorage::SetOfObjects::ConstPointer all = m_DataStorage.Lock()->GetSubset(predicateAllImages);) inside PlaneGeometryDataVtkMapper3D::GenerateDataForRenderer.

I found out that the 3D render window of the StdMultiWidget does not render the data if the widget-plane helper-nodes are removed from the data storage.
If the widget-plane helper-nodes are available but hidden only from the 3D render window (set visibility for that render window to false using properties), the 3D render window does not render the data.
If e.g. one widget-plane helper-node is visible that 2D plane allows to render the data inside the 3D render window, but only the specific 2D plane is visible and not all three view directions.

We discovered that it is currently not possible to use RenderWindowViewDirectionController::SetViewDirectionOfRenderer to change the view direction / rendering of a render window to 3D.
@s434n found out that in order to show the 3D rendering other render windows need to provide the three 2D views for the object in order to have data available to render.

In T24398#244802, @floca wrote:

Have you pushed your clean ups? Not that your efforts get lost. 😉

In T24398#242008, @kislinsk wrote:

In T24398#241998, @floca wrote:

Our side or also the CTK part.

Hm, lets put it as known issue and discuss its priority when we plan the spring release.

Only looked into our side so far. I'll create a separate task and push my clean-up that I already did so far.

Without a data sample we are not able to reproduce this issue. Can you upload one of these nrrd files? Please make sure that the data does not contain any personal information. You can also restrict access to uploaded files to certain users like me.

Unfortunately, it is all nrrd files. I updated my nvidia drivers and it seems to have improved slightly in that it doesn't crash within moments of loading a base nrrd file, but after I create, save and remove a segmentation nrrd, MITK Workbench crashes when I try to reload (open) the segmentation nrrd.

Pushed new branch to rMITK MITK: feature/T29295-monai-tool-httplib.

Without any extra preferences, it's as easy as adding the line this->LoadNextUnfinishedTask(); at the end of the OnTaskListChanged() method.

Deleted branch from rMITK MITK: bugfix/T29434-CleanUpPrefPtrAntiPattern.

Thanks for reporting. We are not aware of any crash like this with valid nrrd files. Since ITK snap crashes as well it could be a strong indicator that the crash is happening in the ITK reader that we use as well. It could be probably related to a corrupt nrrd file, or, in case it is a huge file, it could be simply related to running out of memory. Anyway, without the data we are not able to reproduce this issue.

Pushed new branch to rMITK MITK: bugfix/T29434-CleanUpPrefPtrAntiPattern.

Deleted branch from rMITK MITK: feature/T29025-PreferencesCoreService.