In T26172#226931, @kleina wrote:

Ehm... I cannot do Interpolation in MultiLabelSegmentation I think. Shouldn't there be a drop down?

Is this task still valid? If I try what's written in the description (after showing the interpolation widget), nothing happens, not even on the first label.

In T28142#226704, @floca wrote:

@kalali Aren't you already working on that topic? I thought, i just reviewed something in that direction?!?

Ok I don't really understand how to work with the ExtractSliceFilter and how to replace what's currently done inside PlanarFigureMaskGenerator::CalculateMask(). Maybe someone can help and explain the different usages of ExtractSliceFilter and ExtractImageFilter and how to correctly set the desired slice for the slice filter.

I just realized that PlanarFigureMaskGenerator is still using the ExtractImageFilter from this module. Other classes use ExtractSliceFilter (which is the recommended version). So in order to remove the ImageExtraction-module, I will replace the filter inside PlanarFigureMaskGenerator.

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.

Another deprecated class: Just found out there is a QmitkOtsuAction inside the org.mitk.gui.qt.segmentation, which is not listed in the files.cmake-file. It was deprecated in rMITKc9037280cb9f: made otsu action deprecated and removed it from DataManager and it's not used anywhere anymore.

I went through the relevant plugins and modules and looked at the warnings and errors. I will post some of the ones that I deem to be important for a workbench user, others I left out.

I created D525 (which failed, because I created a local branch on top of another local branch). However, you can have a look at it.
The way I solved the mentioned problem is by using strings for the data type specification instead of using the data type / class as a template.
I think it would be better to find a different solution. One way to solve this would also be to wait until your segmentation-refactoring is finished and the redundancy of the segmentation / multi label segmentation plugins has been resolved. Then we can put the QmitkDataSelectionWidget back into this single plugin. However, it would still be beneficial to have the QmitkDataSelectionWidget available for other plugins so I guess something general like the org.mitk.gui.qt.common plugin would be nice.
Maybe we can discuss the problem of templated node predicates in the mentioned task T27090: Provide standard NodePredicates.

I looked into moving this class but for the predefined predicates some classes are required that are only available inside the Segmentation module. So if we move this e.g. to org.mitk.gui.qt.common plugin we would add an additional module dependency to that plugin, which is unfortunate, I guess.

I agree. But I think (and you also stated this in the merged task T27131):

Further the question arised, if we should refactor QmitkDataSelectionWidget or completly deprecate it and use NodeSelectionWidgets directly.

I checked some of the most important plugin views and their storage inspectors / selection widgets and couldn't find something that needs to be tackled right now. I will close this task for now but we should keep an eye on the "helper nodes" appearing in some selection dialogs of specific plugin views.
And I agree that the the local plugin view should care for the right predicate.

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.

Due to the refactoring of the (MultiLabel) Segmentation modules / plugin views we postponed this again. We need the functionality to explicitly address specific labels of a label set image so that we can compute the center of mass of a specific label.
Also, in the long run we don't want to rely on the data manager / context menu to select the current segmentation / jump to the current segmentation but rather provide additional possibilities (e.g. inside other plugin views) to focus the camera view to a segmentation mask.

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.

The latter function bool RenderingManager::InitializeView(vtkRenderWindow *renderWindow, const TimeGeometry *geometry, bool initializeGlobalTimeSNC), using the initializeGlobalTimeSNC is rarely used at all, only in

• QmitkToFUtilView::UseToFVisibilitySettings
• QmitkDataNodeOpenInAction::OnActionTriggered
• ReinitAction::Run
• LabelSetJumpToAction::Run

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

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.

What is the status here?

My conclusion / suggestion so far:

1. RenderingManager::RequestUpdate*-functions add render windows to a list of render windows to be re-rendered, where re-rendering means updating the graphics / pixel (OpenGL)
2. RendereringManager::InitializeView*-functions (changed to RenderWindowManager::InitializeView* in D517) update the Time- / Slice-Navigation controller and the camera controller to a specific view ("field of view").

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:

To add to this: Point 2 sounds reasonable and that's what happens when the MITK mode is activated: The Segmentation Tool deactivates the left mouse click of the MITK mode.
However, this is not implemented for the PACS mode and would require additional complex logic.

I know that there is a problem with Windows / OpenGL using MITK remotely. I just had never seen this particular error-message given in the description. I will ask about the latest release and an updated driver, thanks!

The point is: I'm removing the InitializeView*-functions from the RenderingManager to separate the repsonsibilities. For these functions to work I now want to pass the RenderingManager as an argument - but this is not working with an IRenderingManager, which I get returned by the mentioned classes.

I changed all occurrences of the InitializeView*-functions and built different MITK configurations to be sure not to miss anything.

All InitializeView*-functions do not need anything from the RenderingManager except for the list / vector of render windows and the time navigation controller - both can be retrieved via public functions. I started separating the rendering functions from the view resetting functions to have two distinct classes with clearer responsibilities.

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

It is important to understand the differences between the following functions:

• RenderingManager::RequestUpdateAll
  • basically goes through all the registered render windows and calls RenderingManager::RequestUpdate on each one
• RenderingManager::RequestUpdate
  • sets the status of the given render window to "RENDERING_REQUESTED" and generates a rendering request event
  • QmitkRenderingManager::GenerateRenderingRequestEvent
    • this is an implementation of the abstract function which simply adds a QmitkRenderingRequestEvent to Qt's post event queue. If the event queue is processed and a QmitkRenderingRequestEvent::RenderingRequest is detected, RenderingManager::ExecutePendingRequests is called
  • RenderingManager::ExecutePendingRequests
    • goes through all the registered render windows and calls RenderingManager::ForceImmediateUpdate on each one that has the status "RENDERING_REQUESTED" set
  • RenderingManager::ForceImmediateUpdate
    • here the actual rendering is initiated by calling vtkWindow::Render on a given render window

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.

For a more thorough investigation of possible side-effects I will list the occurrences of similar code and see if the mentioned solution could be applied there.
I already started doing that some time ago in T26496: [mxn multi widget] Re-initializations reset all render windows and will continue there:

In T26496, @kalali wrote:

I propose to first gather different actions which lead to an update request.

Deleted branch from rMITK MITK: T27498-Set-selection-mode-to-auto-selection.

Just for testing purposes: I created an additional Enum value to mitk::RenderingManager::RequestType, called NO_UPDATE. I'm using this new value inside QmitkSegmentationView::CreateNewSegmentation, for the call mitk::RenderingManager::GetInstance()->InitializeViews(referenceImage->GetTimeGeometry(), mitk::RenderingManager::NO_UPDATE, true);.

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.

Task for a long-term solution: T27613: Improve reinit behavior

The active render window can be selected using the render window manager but it is not possible to do it the other way around - clicking inside a render window does not activate this render window.