Looking through the checklists I found that the 2D tools of the segmentation view are different than the 2D tools of the Multilabel segmentation (one more: Fast Marching is missing). The 3D tools of the multi label segmentation even contain only the Threshold tool.
Thinking about the idea of the MultiLabel segmentation (and that our normal segmentation view also generates labelset images) it should actually not make any difference and thus the tools should be the same (2D and 3D are of course different).
Also, there seems to be a lot of redundancy UI-wise so even having multiple segmentation views and the 2D / 3D tool view for both views seems unnecessary. I would keep that in mind while refactoring the tools. But I am open for discussion on this topic.

In T28118#216794, @kalali wrote:

Looking through the checklists I found that the 2D tools of the segmentation view are different than the 2D tools of the Multilabel segmentation (one more: Fast Marching is missing).

What do you mean with different. Different in there behavior or a different selection of tools.

Regarding the selection, I think you are rigt and there should ultimatly be no difference. But for the current strive for getting things cleaned up and in shape, it is of lower priority. I am happy, if we get through with the fundamental rework and time consistency stuff for this release.

Thinking about the idea of the MultiLabel segmentation (and that our normal segmentation view also generates labelset images) it should actually not make any difference and thus the tools should be the same (2D and 3D are of course different).
Also, there seems to be a lot of redundancy UI-wise so even having multiple segmentation views and the 2D / 3D tool view for both views seems unnecessary. I would keep that in mind while refactoring the tools. But I am open for discussion on this topic.

Yes, I am tending in the same direction. But for know (this release) I would "only" remove in tool UI elements and get the tools themself straight. How to deal with the views and the tools they offered we should discuss seperatly. @kalali could you open a task for that?

In T28118#216941, @floca wrote:

Regarding the selection, I think you are rigt and there should ultimatly be no difference. But for the current strive for getting things cleaned up and in shape, it is of lower priority. I am happy, if we get through with the fundamental rework and time consistency stuff for this release.

Yes, I meant different selection of tools. This does not make sense to me, even more so if we agree on

[..] it should actually not make any difference and thus the tools should be the same (2D and 3D are of course different).

I don't know if they behave differently - if the difference is only UI wise, then I agree that this can be tackled in a different task. But if they also use different algorithms, then I still would keep that in mind for the fundamental rework.

Yes, I am tending in the same direction. But for know (this release) I would "only" remove in tool UI elements and get the tools themself straight. How to deal with the views and the tools they offered we should discuss seperatly.

I agree, this might result in substantial changes, but probably in a lot of redundant code removal. I mentioned this here, since I am not completely sure what your refactoring will cover - just to make sure not to overly change already redundant code (e.g getting a duplicate tool straight).
Nevertheless, I will open a task for this.

Pushed new branch feature/T28118-Refactor_SegTool2D_and_derived_classes.

@floca Please delete the feature branch mentioned above if this task is resolved.

Deleted branch from rMITK MITK: feature/T28118-Refactor_SegTool2D_and_derived_classes.