Hey Marco, I had uploaded the models there back in the days:

After talking with Marco, I have looked for the whereabouts of dockerfiles (liver-mri and multiorgan-seg), working commits for MITK (a0dedffb74d) and for MBI-builds (56ad5bf7064) and trained models. @schererj: I sent you this information via email in October 2020, and shared the trained models on the network drives. Can you confirm? What information do you need to keep the shape models operational?

I like the idea of open sourcing the code and making models available as well. If we can roughly clarify how the workload/hurdles would look like in reality, I can also imagine to back the process. Licensing and publication of trained models arises more often lately, thus any solution here can probably also be fruitful for similar endeavors.

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

A current blocker for use of NAKO data, therefore set as high priority.

Done (pm)

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.

Test data is up now

Added a new test for the simple volume import. The test is run on a small DICOM dataset with sloppy entries for the affected DICOM tags. Also, functionality of the mitk::DICOMFileReaderTestHelper has been extended to check for single block output.

Pushed new branch T23165-simple-volume-import-testing.

Two built-in features of the DICOMITKSeriesGDCMReader cause the false import of this dataset: the number of frames splitting criterion, and the equidistant block sorting step. The problem has been solved by adding a less-strict DICOM import option (MITK Simple Volume Importer), that disables the features in the class. The case is then handled with the new simpleinstancenumber_soft configuration. On reader selection, the resource is fetched from the DICOM Reader Module through the micro services.

Pushed new branch T23165-image-fragments-from-DICOM-import.

Until further restructuring, image statistics can now be calculated for line profiles, and for non-closed planar figures in general. To this end, the mask generator was extended by poly-line rasterisation.

Pushed new branch T22901-IntensityProfileStatisticsCalculation.

Result from DICOM import.

A dicom example can be found in the internal projects drive: /E132-Projekte/Old/DICOM-MIX-DTH/norajitra/GeometryIssues/i40/anoi40.

Pushed new branch T22900-NoStatisticsCalculationForEmptySegmentation.

Added a fix where the segmentation mask is checked for non-zero entries prior to calculation. If the segmentation is empty, an error message will be displayed without starting the calculation.

Thanks for the hint. It turned out in the end that the default cubic interpolation simply messed with labels on the rotated view planes...

This issue is resolved by setting the nearest neighbor interpolation in the clipped labeling image by default.

The bug occurs for image geomtries with axes non-parallel to the world coordinate system. The reason for this is that after a global-reinit, voxels and viewplanes are non-perpendicular, and with the previous cubic interpolation of the segmentation labels, the observed mis-labeling occurs.

Pushed new branch T22839-LabelNoiseInTheClippingPlanePlugin.

Thanks for the clarification, that explains the rotation of course. We are having problems with some other tools (e.g. with the clipping plane plugin) that came up just in these cases with (permuted) non-unity matrices. Apparently, that is then unrelated with these fixes.

The first fix allows the region growing segmentation to start in high-intensity regions in the first place. Now, there is a remaining issue with the usability, that is, extreme scrolling is required to generate segmentations to span higher differences of image intensities.

In some cases, the fix leads to unexpected results (see attached). That is, re-init / global re-inits cause image rotations.@Miklos, maybe you have an idea where to start fixing this issue?

The reason for the bug seems to be associated with image geometries issues that were also addressed in T22254. That is, after loading clipping planes, orig and segmentations, the problem disappears after a manual reinit.

See attachments.

Pushed new branch T19580-RegionGrowerOutOfBoundsContourCreation.

The reason for the out-of-bounds contour creation lies in the iso contour value of 0.5. The latter causes the contour to be just outside of the image slice geometry for the upper indices, which is then also output in the warning message.

Pushed new branch T22494-region-growing-fix-mitk.

Has been fixed in T19467.

[0fe95e]: Merge branch 'bug-19519-closeAdaptiveRegionGrowingToolOnSegmentationCo

Merged commits:

2016-06-15 17:30:17 Tobias Norajitra [304641]
Deactivate the tool if the segmentation is confirmed.

Deactivate the tool via tool manager on ConfirmSegmentation().

[1bb183]: Merge branch 'bug-19467-ToolManagerDisplayConfiguration'

Merged commits:

2016-03-30 14:33:03 Tobias Norajitra [0b4262]
Style changes.

At the moment, there is one hard-coded configuration for all tools, i.e. the one that is set in the Tool::Activated method. This can be fixed by a configuration member which can be modified by the according tool subclasses.
To this end, we have set the "DisplayConfigMITK" configuration as a default setting in the Tool-class, and the "DisplayConfigMITKNoCrosshair" configuration for all 2D tools.

Reason for the bug is within mitk::LevelWindowManager::SetLevelWindowProperty, where node selection according to the handed-over levelWindowProperty is made using NodePredicateProperty. If all loaded images are identical, the node predicate property simply delivers the first node with regard to the otherwise identical level window properties of the identical nodes.

The issue is resolved using an explicit pointer-based comparison of the level window property.

Lower threshold is set to one standard deviation below mean gray value for the upwards growth case, in order to fix the issue.

More specifically, from the seedpoint neighborhood, the mean gray value is chosen as lower threshold for 3D region growing. Thus, gray value variance is not taken into account, leading to an excluding behaviour of the subsequent region growing.

[fa6ed3]: Merge branch 'bug-19359-lowerThresholdAutoChoiceAdaptation'

Merged commits:

2015-10-07 16:07:23 Tobias Norajitra [16771b]
Adjust lower threshold by neighborhood gray value standard deviation. In addition, replace hard coded out-of-bounds value by according numeric trait bounds.

The stated observations are in accordance with the desired behaviour: the segmentation preview is generated via shifting the level window according to the region growing bar in the tool controls.

[8228c7]: Merge branch 'bug-19277-GetScalarValueMinMax-Recomputation-Documentati

Merged commits:

2015-09-02 16:36:07 Tobias Norajitra [94d88f]
Misspelling corrected.

Proper documentation suggested.

The according test image is attached in T19250.

Float image exhibiting faulty binary threshold segmentation.

Float image exhibiting faulty binary threshold segmentation.

The segmentation result appears to be valid, but the preview is faulty in the given case. This seems to be strongly related to T14652, as a very small level window range is being set in the binary threshold tool on threshold changes.