Deleted branch from rMITK MITK: T27100-Revise-DataManager-Plugin-Documentation.

Deleted branch from rMITK MITK: T27100-Develop-integration.

We updated the checklists.

@kahl So are you working on this? If not, could you remove yourself as the assignee of this task?

I tested this with the related review and the fix c042953a0088 solves this issue.

Related: T29088: [Checklist] 3D Segmentation - Checklist and MITK UI Inconsistencies

I guess the wrong signal of the widget is connected here as the number should only be applied after it is completely entered. The correct signal should be editingFinished().

Regarding the comment of closing the contour with a double click: I also realized this during my work on the new add tool and I think the way I fixed it was to modify the OnFinish() function in the mitkLiveWireTool2D to check whether the click was performed on the first point which was also how it was done before the closure contour was added to the LiveWire tool.
Here is the code of my new add tool branch where I changed it:
https://phabricator.mitk.org/source/mitk/browse/feature%252FT28464-new-add-tool-2/Modules/Segmentation/Interactions/mitkLiveWireTool2D.cpp$344

The first two comments should be targeted for this release. The last comment is something that also happens sometimes with the new implementation of the polygon tool that uses the same base class. But fixing is too complex to be worth spending time before the release, so whoever grabs this task, focus on the first two comments.

All checklists have been refactored and used again for testing MITK 2022.04.
Some issues with the checklists still exist, so I will use this task to fix these for the upcoming release:

This is due to the change in the plugin ID . MultiLabel Segmentation View does not exist any more.

I guess the text should state something like

This tool provides a watershed based segmentation algorithm. For a detailed explanation of the parameters level and threshold, please be referred to https://itk.org/Doxygen/html/classitk_1_1WatershedImageFilter.html.
Remark: The tool is faster if you use higher values. So in doubt you should start with higher values (undersegment the image) and then lower the values until you find the anticipated number of segments.

Has been solved with b2f602ab37d5 by merging / landing D601.

Was adapted for the 2021.10 release with the following findings:

• T28815: [Segmentation] Segmentation is still rendered after "clear" was clicked

Was adapted for the 2021.10 release with the following findings:

• T28816: [Segmentation] "New Segmentation" dialog to small
• T28815: [Segmentation] Segmentation is still rendered after "clear" was clicked

Segmentation tests with different labels / on different layers have been added because of T28142: [Segmentation] Remove plugin redundancy with MultiLabelSegmentation / D601.

Segmentation tests with different labels / on different layers have been added because of T28142: [Segmentation] Remove plugin redundancy with MultiLabelSegmentation / D601.

Pushed new branch to rMITK MITK: feature/T28464-new-add-tool-2.

All 3D tools that subclass QmitkAutoSegmentationToolGUIBase provide the "Overwrite"-checkbox, since it is implemented there. This holds true for

• FastMarching3D
• Otsu
• Watershed
• (UL) Threshold
• Pickin

In T27637#233500, @floca wrote:

In T27637#233382, @kalali wrote:

You can see how it feels and looks when the differential for the mentioned task is uploaded. However, I am not sure about point 1B and if we should rather create a first initial label when creating a new segmentation (node).

with this point I am also unsure. From first impulse I guess I would find it annoying, if I always have to explicitly generate the first label. So I would always add at least one new label.

In the future, I think, it makes more sense to add a preference where people can specify a custom lpset file that is always used on new segmentation creation. Then they can decide if the want labels and which one.

The test of the decisions is fine from my POV.

In T27637#233382, @kalali wrote:

You can see how it feels and looks when the differential for the mentioned task is uploaded. However, I am not sure about point 1B and if we should rather create a first initial label when creating a new segmentation (node).

with this point I am also unsure. From first impulse I guess I would find it annoying, if I always have to explicitly generate the first label. So I would always add at least one new label.

I worked on this while working on T28142:

We again concluded that this information + some optional extra features should be shown by a view instead of the task bar. The idea is to have a kind of "core" view like the slice navigator that is usually shown in all perspectives but in the end is configurable.

We decided to have a workaround for this issue (related to T28640: [Segmentation] Add tool checks for dynamic plugin view) so that this tasks does not block T28142: [Segmentation] Remove plugin redundancy with MultiLabelSegmentation.
We will continue working on this issue later this year if T28524: Refactor LabelSetImage and associated classes. is done.