We need to rethink / refactor our (multi label) segmentation tools / algorithms in order to fix them / optimize with respect to the following properties:

• usability of the tools
• efficient resource utilization of the algorithms
• correctness of the implementation (bugs)

At first we need to find out which of the current tools are used / problematic. For this we will open a survey to ask the MITK community.
The outcome might be that we need to refactor or remove some of the existing tools and add new, modern sophisticated segmentation algorithms.

This issue is already known and widely discussed; some related tasks are:

• T28275: [Segmentation] AdaptiveRegionGrowingTool must be refactored / 4D Segmentation returns error message when point is not on the correct timestep
• T28131: [MultiLabel Segmentation] 3D Threshold tool does not work with multiple labels / layers
• T28247: [Segmentation] Watershed tool freezes when slider and threshold are set to a low value
• T28464: [Segmentation] New Add/Remove tool
• T28406: [Segmentation] Examine Live-wire tool for different costfunctions/behavior
• T28244: [Segmentation] Fast Marching Tool not really responsive for large images
• T26970: [Segmentation] Picking tool: When no region is picked, selected node just gets unselected
• T27684: [Segmentation] Improve Region Growing 2D algorithm and interaction
• T28320: [Segmentation] Region growing does not work if seed point is already inside a segmentation
• {T27897}
• T22388: Fill/erase tool in segmentation plugin doesn't work with strg

In general the Segmentation module / plugin and the MultiLabel Segmentation module / plugin need to be overhauled, which will be done here T28176: [Segmentation] Inspection of module and plugin and here T27807: [MultiLabel Segmentation] Inspection of module and plugin.

Resolving the redundancy between Segmentation view and MultiLabel Segmentation view should be done first. T28142: [Segmentation] Remove plugin redundancy with MultiLabelSegmentation.
Everything else (like T28176 or T27807) should be reevaluated after the redundancy (in views and code base) is resolved (e.g. could be that some issues are obsolete then, or that new will be found, but at least maintanance will then be easier as we have then a single source of truth.)