Reason for the sluggish behavior could be rooted in mitk::ContourModelUtils::FillSliceInSlice(...). This is triggered with every mouse move and is currently a single threaded vtk code (handcrafted for loop) that iterates over the whole image. Much becomes very costly for large images. :(
May be at least multi thread the code?

I stumbled upon this again as I was working on an issue with the SliceNavigationController. I suggest to remove the QmitkSliceBasedInterpolatorWidget completely as it is not used anymore.
@s349i is making his changes inside QmitkSlicesInterpolator. As far as I remember QmitkSliceBasedInterpolatorWidget was the interpolation-widget used inside the QmitkMultiLabelSegmentationView, which was removed when the two segmentation views were merged (see 6582705bee86).

I found a line of code where the function is actually used:
Inside QmitkImageNavigatorView::SetStepSize:

if (m_IRenderWindowPart)
{
  mitk::BaseGeometry::ConstPointer geometry = m_IRenderWindowPart->GetActiveQmitkRenderWindow()->GetSliceNavigationController()->GetInputWorldGeometry3D();

This could be related: https://github.com/MITK/MITK/pull/262/

Additionally I found out that the order of the pixel-position and the index do not match, see screenshot (taken with MITK 2022.04 Release, using Pic3D and brain):

Deleted branch from rMITK MITK: feature/T28866-timepointaware-segmentation.

I think this ultimately leads to these two tasks: T25105: UpdateStatusBar duplicates business logic and T19470: Cleanup DisplayInteractor with the goal to remove the UpdateStatusBar-function completely from the mentioned classes and handle the events correctly, e.g. inside the SliceNavigationController or similar. Not only would this remove the mentioned redundancy of the function but also take away the responsibility for updating from the mentioned classes and give it to a more related class.

This is probably caused by DisplayActionEventBroadcast (was DisplayInteractor before).

I've replaced the function used from Modules/Segmentation/Algorithms/itkContourExtractor2DImageFilter.h with a Unary Functor that uses itk only. The file is no longer useful. Maybe I'll delete it and close this if no one objects. The itk file with the same name will be superseded by the one provided by itk with the same name.

I would like to discuss if we want to tackle this problem. It is related to T27613, which is still open.

Deleted branch from rMITK MITK: bugfix/T28274-volumerendering-multiple-timesteps.

In T26399#238936, @floca wrote:

In T26399#238893, @kalali wrote:

I'm not sure if this is the reason (T24348: Invalid pointer exception due to invalid QModelIndex in QmitkDataStorageTreeModel) for the decision. I would go the route to deprecate the QmitkDataStorageModel and replace it with the QmitkDataStorageSimpleTreeModel.
However, the QmitkDataStorageSimpleTreeModel probably needs to be extended (e.g. dropping, changing hierarchy). Do we already have a task for this / should we tackle this in this release-phase?

This should be carefully discussed. I think some of the features QmitkDataStorageModel does not belong in a model.

In T26399#238893, @kalali wrote:

I'm not sure if this is the reason (T24348: Invalid pointer exception due to invalid QModelIndex in QmitkDataStorageTreeModel) for the decision. I would go the route to deprecate the QmitkDataStorageModel and replace it with the QmitkDataStorageSimpleTreeModel.
However, the QmitkDataStorageSimpleTreeModel probably needs to be extended (e.g. dropping, changing hierarchy). Do we already have a task for this / should we tackle this in this release-phase?

This should be carefully discussed. I think some of the features QmitkDataStorageModel does not belong in a model.

In T26399#238877, @kalali wrote:

@floca What was the reason for this: What does "would not reflect the data storage graph anymore" mean? Does the classic / original QmitkDataStorgageTreeModel have any drawbacks because it changes the "internal representation" by changing the parent?

In T26399#238874, @kalali wrote:

@floca : Ilooked into this again and found the following:
This is a problem because inside the AddNodeInternal-function the tree is rebuilt by checking the parent-child-node hierarchy and adding tree-items accordingly. However, the hierarchy at that time is incorrect and already outdated.

Good that you identified the problem.

I'm not sure if this is the reason (T24348: Invalid pointer exception due to invalid QModelIndex in QmitkDataStorageTreeModel) for the decision. I would go the route to deprecate the QmitkDataStorageModel and replace it with the QmitkDataStorageSimpleTreeModel. However, the QmitkDataStorageSimpleTreeModel probably needs to be extended (e.g. dropping, changing hierarchy). Do we already have a task for this / should we tackle this in this release-phase?
I stumbled upon these different tasks because of T26394: [Render window manager] Provide tree view / model, which is related to the mxnMultiWidget.

See T16165: Reinit after deletion for a reasoning. Both tasks are justified but maybe we should highlight / utilize the general preference "Call global reinit if node is deleted" more.

My changes related to this task were mainly to clear some classes and remove uncertainty (see T28617: Inconsistent view initialization in rendering manager).
As far as I see it some changes have been made in the subtask T28490: Segmentation plugin: "new" segmentation should not run reinit! and the respective D523: This was mainly concerned with NOT resetting the view / camera using a newly introduced parameter "resetCamera".

In T26399#238874, @kalali wrote:

• move the node-tree-items to their new parents immediately inside the QmitkDataStorageSimpleTreeModel::NodeRemoved, like it is done here: https://phabricator.mitk.org/source/mitk/browse/develop/Modules/QtWidgets/src/QmitkDataStorageTreeModel.cpp$675-684

I quickly tested the second suggestion and I was not able to reproduce the bug anymore.

@floca : Ilooked into this again and found the following:
After a node has been removed, inside QmitkDataStorageSimpleTreeModel::NodeRemoved the function QmitkDataStorageSimpleTreeModel::UpdateModelData is called. Here the data storage pointer is used to retrieve the data node subset of a given node predicate. The returned nodeset still returns 6 nodes in my case, although only 5 should exists, since one node was removed.
The node still exists in the data storage, because the signal for a node being removed (RemoveNodeEvent) is sent before the actual removal of the node from the list of nodes inside StandaloneDataStorage (data member m_SourceNodes)).

Instead of command output string parsing, the plan is to export available models' information and place it in a machine-readable format (eg. JSON) in the RESULTS_FOLDER.
This file can be further read by MITK and shown in GUI.
So, this involves making changes on the Python side, as well, for the dumping of the information in a machine-readable format (eg. JSON) natively.

The output of the abovementioned command, for reference:

Started dicussion about it. Current discussion result: We should go for a new model view based implementation instead of try to fix the current boiler plate code.
Have to discuss design of the model view pattern in detail in the next MITK meeting.

in the new data structure it won't happen as there is no active label anymore. But you are right I thought the same when I looked through the class. My motiviation to refine this obsolete class was only limited 🙈 .

I just stumbled upon the following:

yes, that will help. Also, this worklist will be quite helpful, allowing a new form of "batch-processing".

@gaoh maybe also the worklist feature covered by T29159 would also help/suffice? Than you could explicitly define the output path.

Yes. My work will take care of this. Just need to finish off the label merging for individual slices.