Has been solved for the segmentation plugin and the multilabel segmentation plugin.
A general reformatting of the resetting-functionality will happen in T27613: Improve reinit behavior.

A first differential was created. There is another class QmitkThresholdAction that is not included anywhere and has not been touched for a long time. I don't see any reason for keeping this class. So I updated the differential with the removal of this class as well.

When I look for occurrences of mitkOverwriteSliceImageFilter, I see a description inside ApplyDiffImageOperation and DiffImageApplier that says

At the moment, ApplyDiffImageOperations are only created by OverwriteSliceImageFilter.

or

Instances of this class are created e.g. by OverwriteSliceImageFilter.

However, the mentioned mitkOverwriteSliceImageFilter is nowhere used and was replaced by mitkVtkImageOverwrite. I found occurrences of ApplyDiffImageOperation and DiffImageApplier inside QmitkSlicesInterpolator.cpp, so I changed the description accordingly.

Comment: One should seperate the open todos into sub tasks, I think.

In T28490#226519, @kalali wrote:

Also, this solution still does not preserve the zoom but that's the next step.

We discussed this and two important points were made:

• The difference between RenderWindowManager::InitializeViews(RenderingManager::GetInstance(), image->GetTimeGeometry()); and RenderWindowManager::InitializeViewsByBoundingObjects(RenderingManager::GetInstance(), dataStorage); is reasonable and important - even for a single data node (e.g. brain.nrrd, where the image itself is somehow rotated / tilted).
• We definitely want to reset the geometry automatically such that the current view geometry of the renderer matches with the segmentation geometry. That way the user can immediately start drawing. We don't want the user to have to care for the correct geometry aligning manually.

In T28490#226107, @kalali wrote:

We need to look deeper into the segmentation plugin to find out if it is possible to create and draw a segmentation without a correctly initialized reference image.

Deleted branch from rMITK MITK: bugfix/T28385-AddNullptrCheck.

Pushed new branch to rMITK MITK: bugfix/T28385-AddNullptrCheck.

Deleted branch from rMITK MITK: bugfix/T28385-InterpolationCrashOnMorphologicalOperations.

Pushed new branch to rMITK MITK: bugfix/T28385-InterpolationCrashOnMorphologicalOperations.

So I dug a little bit deeper using brain.nrrd as test data:

We can fix it in the SegmentationInterpolationController by explicitly handling the situation that the modified image is not initialized (IsInitialized() == false).

In T28490#226107, @kalali wrote:

So my conclusion from this: [...] It seems as there is a difference between the initialization that is performed when loading the image and the initialization that is performed when calling InitializeViews or using the reinit-action from the context menu.

I see no difference between calling InitializeViews with the new Enum value NO_UPDATE and not calling InitializeViews at all, solely using mitk::RenderingManager::GetInstance()->RequestUpdateAll() to correctly set the rendering geometry without changing the view after a new segmentation nodes has been created.
However, both variants do not allow segmenting on the new segmentation node as the warning message shows, stating that a reinit should be performed on the segmentation image. The warning message appears in the scenario where I changed the camera view before creating a new segmentation:

After a new segmentation node was been created, it is added to the data manager. This event itself will call RequestUpdateAll multiple times. However, the view will not be reset with the mentioned new value NO_UPDATE - that means, requesting a render update does not change the view / crosshair / camera orientation etc. The view is only updated / reset when InitializeViews or InitializeViewsByBoundingObjects is called (which in turn calls InternalViewInitialization and updates the slice navigation controller).

A first idea was mentioned here:

In T27613#225754, @kalali wrote:

Just for testing purposes: I created an additional Enum value to mitk::RenderingManager::RequestType, called NO_UPDATE. [...]

This allows to disable resetting the view / crosshair etc. after a new segmentation has been created.

The QmitkNewSegmentationDialog, which is used for the "New-button" does not contain any logic for resetting the render windows.
It can be used to simply create a new segmentation, e.g. when using the QmitkCreateMultiLabelSegmentationAction from the data manager context menu - here this dialog is used but no re-initialization / view resetting is done.

We should look into this and focus on the mentioned related task by @kislinsk to start with separating the two processes:

1. matching the geometry of the images for interaction
2. resetting the view of render windows to see the new segmentation