I have updated the checklist according to the documented / actual function of the two tools.
However, I had to add a note regarding the "remove everything" functionality of the erase tool, which currently does not work correctly (?) when a segmented region touches the boundary of the image (see T29078 example 2).

Pushed new branch to rMITK MITK: feature/T28578-MxN-development.

In T28464#239595, @floca wrote:

@s434n Have claimed it for finding the error* (good job by the way). Then you can unclaim it now.
Or will you work on that issue further?

After looking into the code, it seems to me that the warning is just formulated wrongly. A simple reinit will not make the bounding box for a rotated image pixel-aligned. Implementing this would take some time and require a lot of reworking the bounding shape interaction. As this is not currently requested, we will keep things as they are and only update the warning text so it won't be misleading.

In T28808#238579, @a178n wrote:

I expect a circle in the cross-hairs, akin to Shape: cross or vertex. But there is None. Is this expected behaviour?

In T29141#238594, @kalali wrote:

Is this the same (T29110, see description point 3) and specifically T29110#235991?
If so, I have a fix for the > layer 0 problem which can be tested and reviewed in D632.

I was able to reproduce the problem on the snapshot from two days ago. This new version fixes the problem for me, although the behavior is the same as @kalali described it. The newly created segmentation is a complete copy of the current one (including layers, labels, and masked regions of the labels), except for the changed region that was just segmented. I'm not sure if this is the expected behavior, but if it is everything seems to work fine.

Correction to my previous comment: all options are rendered. The only thing is, that the "Vertex" option is hardly visible because it is so small in the 2D views. Since the vertex does not change size with the scale property, I would assume this is by design.

Trying with Windows 10 as well as Ubuntu 20.04, I can only reproduce the option "Vertex" making problems. Everything else seems to work, but this option is not shown in any of the 2D views, only in the 3D view. I used openMeAlone.mps and PointSetForPic3D.mps.

I looked a bit into this. As far as I can tell, there is no such functionality available in the ctkRangeWidget we are using, or the QT classes it is based on. Achieving the proposed behavior would require a large rework. Since the demand for this is very low, it won't be done in the foreseeable future.

I was able to reproduce this on Windows 10, but the behavior seems to be very inconsistent. When testing with Pic3D.nrrd and brain.nrrd, I took the following steps:

• load the image
• create a new segmentation
• draw with the Add- / Region growing - tool in one of the views
• draw again with the same tool in a different view

The behavior then differs depending on which views were used. Generally, when first drawing in the axial view and then in either of the other two, the second addition is not drawn interactively but only shown when letting go of the mouse button. This sometimes also occurs when going coronal -> sagittal or sagittal -> coronal, but never when doing the axial view second.
This only happens when using the same tool in both views without deactivating. If I switch the tool or deactivate and re-activate it, the second drawing works perfectly fine.

I am not able to reproduce this problem on Windows 10 using brain.nrrd as test image

From what I can see, the level window is reset to its original state after pressing "Confirm Segmentation". The darkening / changed level window is only temporary to help adjusting the parameters of the region growing. To me this seems like a feature, not a bug. At least it is by design, anyway.

I tested with MITK v2021.10 and the current state of develop and have the same behavior as @kalali: unconfirmed 3D interpolated surfaces (and contours) are drawn in green. To me this also looks like what is expected from the checklist.
I also get the <segmentation-name>_3D-interpolation node.

I tested with MITK v2021.10 and the current state of develop and also can't reproduce the described problem. In both cases unconfirmed interpolation slices are drawn in yellow.

Amir and I took a look at this in the context of his current work on T28142 (see D601). Because of the unification with the MultiLabel Segmentation plugin, another check is needed for the interpolation area, as interpolation is currently not supported for segmentations with more than one label. So there is the general check, making sure the selected nodes exist and their geometries match up, as well as the check for the correct number of labels (exactly one).
Every time the second check is updated (e.g. when a new label is created) we have to either be certain the first one is currently true, or check the first one again. To avoid adding a new member variable and manipulating/checking it in various places, we decided to just redo all checks together in one place, as this doesn't take too long and is only triggered by user input.
This is captured in D604, which is based on D601 though

This has also been adressed in D568 since the problem turned up there in the CI builds. Should we still solve it in D582 separately or just wait until D568 can be landed?

I think related to this task: it seems there is some more inconsistency depending on the shown region. When two images with different geometries are loaded and shown simultaneously after a global reset, planarfigures created on one of the images can extend into the whole shown region, outside the boundaries of the selected reference image (even after a reset on that specific image).
It seems in this case the boundaries for the planarfigure are set incorrectly on creation.

I can't reproduce the problem mentioned for the mapper plugin on v2021.10 . The moving / target information appears in the properties, just as in a registration created via the Algorithm Control plugin.
Can somebody reproduce this (or a related) problem? Otherwise I guess the task was already solved somewhere else and can be closed