The 2D region growing tool fails if you try and start it from a seed point inside a low intensity image region like the lung e.g. in MRI. Expected behaviour is that a region contour is displayed that changes if the threshold is adjusted via up or down mouse movement. Nothing happens instead. Priority set to high since it makes MITK unapplicable for commonly encountered scenarios like manual segmentation e.g. of said low intensity regions.
Revisions and Commits
|Restricted Differential Revision||rMITK99e147b96882 Keep region grower thresholds within the pixel type extrema of the reference…|
|Restricted Differential Revision||rMITKaf6ba9b47f82 Keep region grower thresholds within the pixel type extrema of the reference…|
- Mentioned In
- T27684: [Segmentation] Improve Region Growing 2D algorithm and interaction
T27638: 2020 Week 31
T27143: Matchpoint Registration Evaluator- Colorblend Bug
T22620: Region growing doesn't work within high intensity regions
T19318: Region growing doesn't work on very light or dark patches
- Mentioned Here
- T27143: Matchpoint Registration Evaluator- Colorblend Bug
T26167: ExtractSliceFilter handles 3D+t images inefficiently and inconsequently
do you know when this stopped working?
The error was first noticed recently while working with clinical partners on MRI lung data from the NAKO. I checked the old installer from 2015, where it also did not work.
or someone else: is there an example image in MITK Data to show this behavior?
I could not find a suitable lung example in MITK Data. I checked on two old lung MRI datasets in the department, where the problem did not occur.
Does the MITK team have access rights on the NAKO dataset? Then I would suggest an example from there.
I put a _non-shareable_ dataset in /ad/fs/E132-Projekte/Share/MarcoToMitkTeam .
I could only test the 2018.04.2 release on Linux:
- I can confirm the behaviour is strange ;)
- however, maybe there is a workaround: starting with an initial downward movement after press-and-hold, a contour appears and after that it can be adjusted as usual
@norajitr maybe the workaround could be tested by users right now if it helps. Still a bug though ...
@floca @nolden At this point I would say the task is still a blocker from a clinical point of view. The tool is somewhat usable, but still not always working as expected thus making it inconvenient and non-intuitive. Sometimes for example, the region growing cannot be further expanded in contrast to the similarity of nearby image intensities, sometimes it takes several trials at different seed points. Altogether, this makes the tool work differently than one would expect. Also sometimes, the tool displays some kind of 'lag' when waiting for region updates (i.e. mouse position updates that had just worked suddenly have no more effect).
Another issue I noticed while working on region growing:
The ToolManager reference and working slices are 2d according to their details, but the number of slices is set to 2. An additional empty slice is drawn if these images are added to the data storage for inspection.
This bug was introduced in T26167: ExtractSliceFilter handles 3D+t images inefficiently and inconsequently in the ExtractSliceFilter, so more or less every sliced image by this filter is affected. One of the overloads of Image::Initialize() that uses a PlaneGeometry as input is called with the parameter sDim set to 2. I guess the meaning of this parameter was simply misinterpreted as image dimension instead of number of slices.
Oof, that took a while. I narrowed it down to the itk::ConnectedThresholdImageFilter, which takes a seed point, a lower, and an upper threshold. I verified that the seed lies within the thresholds and still the output image was empty for low intensity regions.
Here's the thing: The image has unsigned short as pixel type, yet the level window range spans from -2000 to 4000 and even the default visible window range starts at values below zero. The region growing depends on the level window and all the threshold calculation is based on it. So we are feeding signed thresholds into the itk::ConnectedThresholdImageFilter which are implicitly converted to huge unsigned numbers, often resulting in an extremely high lower threshold and an upper threshold that is smaller than the lower threshold.