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?

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.