Page MenuHomePhabricator

[Segmentation] Redundant label "recomputation" for Otsu/Watershed (& nnUNet) when any of the Preview-generated labels are selected to Confirm
Open, Needs TriagePublic

Description

In the segmentation tools deriving from AutoMLSegmentationWithPreviewTool tool manager class viz. Otsu and Watershed, when Preview labels are selected for Confirmation; the tool requests the segmentation to be recomputed. In other words, ComputeMLPreview method is called again when a label in the QmitkSimpleLabelListWidget is selected for the first time.

Steps:

  1. Load image into the workbench
  2. Open Segmentation plugin -> Otsu Tool
  3. Click Preview (now OtsuTool3D.ComputeMLPreview method is called to compute a segmentation)
  4. Now click on any of the labels listed in the list widget below.

Again, a redundant call is made to OtsuTool3D.ComputeMLPreview method to recompute the same segmentation.

However, a redundant recomputation never really happens numerically due to some checks implemented in the tool's ComputeMLPreview method to circumvent this behaviour. This is why we don't see a performance drop.

Event Timeline

After some analysis, it is understood that there is a difference in the modified time of the tool and the segmentation. This is detected in the AutoMLSegmentationWithPreviewTool.DoUpdatePreview method if-case of this->GetMTime() > m_MLPreviewNode->GetData()->GetMTime().
This change in time happens because tool->IsTimePointChangeAwareOn() is called after the tool->UpdatePreview() call is made in the tool's GUI class, eg. QmitkOtsuTool3DGUI

After being discussed in the MITK meeting, the decision is to include an option in the tools for users to select if the segmentation call should be made dynamically for every time step or not. This option can be provided either in the tool itself or in the Preferences. Thus, users can decide when the tool becomes IsTimePointChangeAwareOn()or IsTimePointChangeAwareOff().
This would further imply that the tool->GetMTime() won't change after a Preview is made and thus, a redundant call to ComputeMLPreview can be avoided.