- User Since
- Aug 1 2016, 12:10 PM (261 w, 2 d)
May 20 2021
Hey Marco, I had uploaded the models there back in the days:
May 8 2021
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?
Feb 24 2021
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.
Jun 30 2020
@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).
Jun 17 2020
A current blocker for use of NAKO data, therefore set as high priority.
May 7 2020
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.
Feb 10 2020
Dec 8 2017
Oct 27 2017
Oct 16 2017
Test data is up now
Oct 13 2017
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.
Sep 29 2017
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.
Aug 4 2017
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.
Jul 21 2017
Jun 26 2017
Jun 23 2017
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.
May 15 2017
Thanks for the hint. It turned out in the end that the default cubic interpolation simply messed with labels on the rotated view planes...
May 12 2017
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.
Apr 28 2017
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.
Feb 17 2017
Pushed new branch T22494-region-growing-fix-mitk.
Aug 2 2016
Has been fixed in T19467.
[0fe95e]: Merge branch 'bug-19519-closeAdaptiveRegionGrowingToolOnSegmentationCo
2016-06-15 17:30:17 Tobias Norajitra 
Deactivate the tool if the segmentation is confirmed.
Deactivate the tool via tool manager on ConfirmSegmentation().
[1bb183]: Merge branch 'bug-19467-ToolManagerDisplayConfiguration'
2016-03-30 14:33:03 Tobias Norajitra [0b4262]
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'
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
2015-09-02 16:36:07 Tobias Norajitra [94d88f]
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.