Pushed new branch to rMITK MITK: bugfix/T28833-FixGeometryOfLabelMaskImages.

Oh no, this bug sneaked in with the fix of T28806: Crash in "Create smooth polygon model" for 2-d images. The initialization of the mask images for labels was changed to have the correct dimensions for 2-d images. However, the original transform of the label set image is not lost and has to be set explicitly.

Deleted branch from rMPT MITK-ProjectTemplate: release/T28841-MITK-v2021.10.

Deleted branch from rMITK MITK: release/T28841-MITK-v2021.10.

Pushed new branch to rMPT MITK-ProjectTemplate: release/T28841-MITK-v2021.10.

Pushed new branch to rMITK MITK: release/T28841-MITK-v2021.10.

Deleted branch from rMITK MITK: release/T28802-MITK-v2021.10.

Deleted branch from rMITK MITK: release/T28802-2021-Week-45.

Pushed new branch to rMITK MITK: release/T28802-2021-Week-45.

Works with Zero and Minimum background value options, only "custom" results in an uncaught "dimension (4) is not in (2)(3)" exception + crash.

Sadly, a few years ago I was overruled by the decision that modifications of a single property should also modify the property list it is part of with the standard Modified() event. This bits back in cases like the Properties View and there is no feasible solution for it under these circumstances. The issue is that modifying a property value in the tree view itself now indirectly modifies the whole property list which must trigger a model reset. A workaround is to always expand everything instead of collapse everything, as it won't fight against most of the users intents regarding nested items. The displayed property list is typically longer now by default but there's a filter widget for that anyway.

Lowering the priority since it is hard to reproduce without any more information and terminal/console output. I am sure that somehow these obscure tools can be forced to crash independent of the hardware. An unsolved question from last release is still: do we want to keep these tools anyway since they are basically unusable for any user and even developer with code insight.

I lower the priority since the exception is caught and it results in an error message instead of a crash. It's also an academic edge case, since it hardly makes any sense in a real world scenario to convert an actual image with more than 65000 different pixel values into a segmentation. Converting binary images or segmentation-like images works as expected.

Turns out that VTK has the same issue as MITK in a few filters regarding recognizing a 3-d image as such when it has only a single slice. To fix it, I also added a check in the corresponding MITK filter that adds an empty pad slice to an intermediate pipeline image output for single-sliced images. Also, the result of the filter pipeline is now checked more thoroughly whether it is containing actual surface data or not. If there is no surface data, no surface node is created but instead a warning is printed for all affected labels and a hint is given to try again without smoothing (smoothing does always smooth out single slices completely).

Thanks for the first look. I come to a slightly different but related conclusion. Segmentations are always created with 3 or more dimensions by design choice. So, for the 2-d image, a 3-d segmentation with the third dimension set to 1 is created. Checking the dimension of that segmentation image returns 3 as expected.

I changed the priority to Wishlist because the behavior is as expected. We can discuss if we want another preference to change the behavior so that visibility changes of parent nodes also affect child nodes.

I guess it is because the Description of the plugin is "View, Set, and Change properties of DataNodes". There are also keywords for plugins (see the plugin.xml of the Properties plugin for example). It is expected behavior.

@floca What is the current status of these two tools?

The thing is, most surfaces that are generated within MITK have a very high vertex count and changing the default point size could lead to a lot of visual clutter. You found already a way to change the point size. BTW, be aware, that in general the Properties view is meant as a Power User / Developer view. Changing properties here should be a last resort for typical users in case there isn't any dedicated widget for the same setting in any other view.

I cannot reproduce it with the latest Windows snapshot installer. I used Pic3D.nrrd + RenderingTestData/PointSetForPicD.mps.

The description of the actual but swallowed exception is "Prohibited image access: the requested image part is already in use and cannot be requested recursively!" thrown indirectly from line 315 in mitkLabelSetImage.cpp: AccessFixedDimensionByItk_n(), which eventually calls ImageToItkImage() in mitkImageToItk.h:132. There, the Update() call of the ImageToItk class throws the exception mentioned above,

100% agree. Also, the fact that the level window has an impact should be made clear by a widget. Maybe even a checkbox to decide if the region growing should depend on true image values or displayed image values.

In T28783#229710, @floca wrote:

I also think that if you realy select a preset it should be aplied, even if it is (partially) out of range. Everything else would have an impact on the visualization and would for example lead to the fact that a certain preset has for the same value different appearances in different images.

In T28784#229713, @floca wrote:

Is it realy a check box element or just an action to apply?

The level window widget really is too cryptic and has too many hidden features and behaviors. At least we need to clarify how it is working / applied currently and what we would expect. With multiple data sets there won't be an optimal solution that pleases everyone as us is dependent on taste/workflow.