This was reported as relevant for medical expert segmentation work

Is there some rough estimate when this bug was introduced?

@norajitr or someone else: is there an example image in MITK Data to show this behavior?
@norajitr do you know when this stopped working?

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.

Does the MITK team have access rights on the NAKO dataset? Then I would suggest an example from there.

Would be great if you could point me to an example.

Done (pm)

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 ...

@norajitr How pressing is this task with the work arround given by @nolden ?

@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).

@norajitr We discussed this today in the MITK 2020 meeting and it stays on the high priority list, no promises regarding a date for a fix but at least some investigation of the underlying cause should happen soon'ish

soon'ish == 2 weeks ;)

Pushed new branch bugfix/T27085-2DRegionGrowing.

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.

In T27085#207102, @kislinsk wrote:

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.

In T27085#207104, @kislinsk wrote:

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.

Uh oh. Sorry, yes, I missunderstood/falsely used the call. Glad you spotted it. I think this could also be the reason for T27143. I will check it as soon this task is closed/landed.

Deleted branch bugfix/T27085-2DRegionGrowing.

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.

*OMG*

Pushed new branch bugfix/T27085-2DRegionGrowing.

Deleted branch bugfix/T27085-2DRegionGrowing.