I don't think it is necessarily a bug, but rather unintuitive how it works. The recentering is not triggered by the clicking of a node, but via changes in the selection. One can also do things like select multiple lines (on different slices), then deselect one, and the view recenters to one of the still selected nodes.
For me, it would feel more intuitive if the view just recenters every time a node is clicked, regardless of the selection. But there is no bug apparent to me here.

Deleted branch from rMITK MITK: bugfix/T29348-ImproveWelcomePage.

Pushed new branch to rMITK MITK: bugfix/T29348-ImproveWelcomePage.

I designed a few mouse navigation icons and put together a first HTML draft:

Okay, cool. Do you proceed and adapt the checklist to close this task?

The way the masking is done inside the QmitkImageMaskingWidget of the segmentation-plugin is different but it works as expected and is easy to understand.
As written in the task description the QmitkImageMaskingWidget of the multilabelsegmentation-plugin provided different options, but they were not used so I think we are safe here.

So far only the minimum was implemented as transparent. So I would not change anything right now.
And before changing it in one color palet, I would tend to think of making it a general feature of the LookupTable class, to say that its visualization is clamp (thus everything outside the lut window gets transparent. (but that would be a new feature request/idea).

From testing, it seems to work correctly in one direction. Everything below the level window is transparent (i.e. black) while everything above the level window is dark red, as the maximum end of the colormap. If this is the desired behavior, it works for me. If we want the upper part to also be transparent, then it is not quite right yet.

With {D744 } being landed we need to check if this also applies for the single remaining Segmentation Utilities view.

I added a task in the "smoothed polygon" section:
Task

extend one segmentation to multiple neighboring slices to create a “3D” segmentation

Result

The segmentation mask is rendered on multiple neighboring slices.

I removed the „Smoothed surface creation“ Preference section from the Segmentation - Options checklist.

We discussed this and we decided to remove the options from the preferences completely. This will be done in the mentioned task T28793: [Segmentation][Multilabel][Options] Changing only decimation rate has no visible effect in "Create smoothed polygon model".

I think there may have been a misunderstanding in this task. With the current description, I am not able to reproduce the problem (zoomed in image when loading).
From the mentioned checklist, I understand it that the tester zoomed in himself, as the checklist recommends, to see if the crosshair is aligned with the pixels. The comment only says "Problem with the brain image. The other are working. Attachment 1", so I assume the image is only to illustrate this.
So the only problem is that brain.nrrd is not pixel-aligned automatically when loaded, only after doing a reinit. I think this step in the checklist is worded a bit unclear anyway, so it's probably best to just improve that instruction and I think that's it.

I tested this and the smoothing works but as stated in the description it should be made more obvious what to do.
As @kislinsk wrote we will not tackle this issue here but instead remove the options from the preferences. However, this is more about the context menu action "Create smoothed polygon model". Should the whole action be removed? Or are we only talking about the additional preferences for "Smoothed surface creation"? If only the preferences should be removed we still need to adapt the checklist to make it more clear how a smoothed polygon should be created.

The confirm string should not be changed. Result of the discussion was only to change the clear string.

A short but clear description of the interaction types is given in the MITK StdMultiWidget Editor help page (F1 on "StandardDisplay"):

I changed the strings according to the suggestions in this task.
However, your last comment only stated to rename the "Clear Segmentation" button.

I updated the "Checklist Segmentation – 3D Segmentation_EN":

• updated tool-image (no region growing, new icon for Picking and GrowCut)
• removed region growing test section, changed order of tool sections
• updated Otsu-tool GUI image
• added description of "Transfer ..." checkboxes
• modified description of "GrowCut"-tool

Deleted branch from rMITK MITK: bugfix/T29350-NodeSelectionDialogNeedsMarginAndSpacing.

Pushed new branch to rMITK MITK: bugfix/T29350-NodeSelectionDialogNeedsMarginAndSpacing.

"Clear Contour" is a good propsal that should be changed.

It works on Windows and Ubuntu. The default hotkey for reinit is Ctrl+R and can be specified in the preferences. Maybe Ctrl+R has already a special meaning on macOS. We need to check but I would classify this task as cleared for further investigation.

I recreated the problem by loading any image (the described ones work, as well as just Pic3D.nrrd) and moving the level windows really far (either by dragging the bar to one direction, or moving it back and forth to the upper and lower bounds), to values around the scale of 4e+38. At that point, the workbench just freezes and stops responding.

The images mentioned in the checklist are:

Since this cannot be reproduced right now, we assume this was caused by user error, maybe clicking at the wrong location. For the upcoming release there won't be anything done about this.
In the long-term, we will have to think about if we want to try and improve level window UX, especially in regard to the MxN multi-widget view (T28578) which may need fundamental changes.

We think that people in the real world do not use the smoothing options at all and checking for their impact revealed that they seem to have no effect at all in most cases. We decided to remove the options from the preferences. In addition, there's a message in the terminal when no smoothed mesh could be created which is the case for some single-slice segmentations. It even suggests to try again without smoothing. However, this should probably be a more prominent feedback as message box for example.

Pixel information has been removed. To add a specific view for pixel information, see T29324: Create view for pixel information.

Pixel information has been removed with {D686}. We discussed that we will open a new task to add a simple pixel value information view as a separate task.

Deleted branch from rMITK MITK: feature/T28607-live-wire-improvements.

Should be resolved with the changes introduced with the lasso tool reworks. Lets wait for tester feedback.

I connected this task with D686: Not all discussed points are handled here but I removed the UpdateStatusBar-functions completely and added a simple function to update the status bar info with the mouse pointer / world position and the global time dynamically.
More code changes will be uploaded to provide ideas on how to show image pixel information.

In T25043#239851, @kalali wrote:

1. Do we agree that there will be no position / pixel value information shown in the status bar?
   1. or are we only talking about the (maybe case-specific) pixel value information; meaning the position / index should still be shown in the status bar?
   2. if everything should be removed from the status bar, we wouldn't put any new functions in the "StatusBar"-class, right?

I would say A. So coordinate information is still visible.

I worked on related topics last week and found some solutions for this problem (and also solving the parent task).
Some questions remain, though:

Close this task. As the "classical" overwrite checkbox is dropped. Region Growing has to be written completly new anyways and then based on mitk::SegToolWithPreview, such features will come for free.

Pushed new branch to rMITK MITK: feature/T27319-multilabelInterpolation.