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.

I'm not sure where exactly this was introduced (maybe in D739), but seems to already be working now.

I just had another look at this. I was able to reproduce the bug this time. It seems that this problem only arises if the image holds floating point values, not when all values are integers.

Deleted branch from rMITK MITK: feature/T28578-MxN-development.

I also can't reproduce this on Windows 10, changing the theme works as expected. So probably really a Mac OS specific issue.

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.

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.

As far as I can tell, this is the expected behavior. Any voxel that has a (greyscale) value above the level-window range is shown completely white. The colors only extend this to multiple channels, but the behavior is still the same. So with very low level-window, the colors are expected to stay visible very strongly

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.

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.

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?