In T29025#243461, @kalali wrote:

I stumbled upon this while working on T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module. I would like to tackle this issue and already started looking into this. Do you already have an idea how to approach it or do we want to discuss it next week?

Required for T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module / T27133: [Segmentation] Is QmitkDataSelectionWidget needed anymore?.

I stumbled upon this while working on T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module. I would like to tackle this issue and already started looking into this. Do you already have an idea how to approach it or do we want to discuss it next week?

Deleted branch from rMITK MITK: feature/T28578-MxN-development.

3. The relevance of the labels list outside models? Perhaps, this entry can be used to describe all labels and their label ids used in the host app. And, models can then refer to label ids in their respective labels entries.

2. Lack of consistency in models->labels entries. For some models eg. deepedit there are label ids along with names, effectively assuming a Map datatype and for others, eg. deepgrow_2d it's a list. of label names. This creates unnecessary corner cases while parsing using strongly typed languages, like C++.

1. There is no indication in the JSON on which models are interactive click guided, scribble guided or automatic. Eg. Deepedit can be interactive click-guided or automatic, GMM+GraphCut is scribble guided, Segmentation Spleen is purely automatic. Hence, the JSON parameter type can be made more consistent for easy grouping.

Deleted branch from rMITK MITK: release/T29377-2022-Week-43.

Pushed new branch to rMITK MITK: release/T29377-2022-Week-43.

Hm, I disagree. :-)

These variables need to point to the location where CMake's find_package() will find the packages. For example, for ITK it would need to point to the equivalent of the MITK-superbuild/ep/lib/cmake/ITK-5.2 folder, where the ITKConfig.cmake and ITKConfigVersion.cmake files are located.

With -DEXTERNAL_ITK_DIR=/usr/local it still downloads and builds ITK.

The superbuild has advanced variables for that:

• EXTERNAL_ITK_DIR
• EXTERNAL_HDF5_DIR
• EXTERNAL_BOOST_ROOT

If D744 is landed, we can close this task. The issue will be addressed here: T29369: [Segmentation Utilities] Handle / select different labels independently.

With {D744} we only have a single Segmentation Utilities view. Labels operation should be added to this and then the issue of this task needs to be considered.

I looked into this and I was confused: the used QmitkRenderWindowDataStorageTreeModel already contains a node predicate for filtering out the helper nodes. When creating the mxnmultiwidget (or a new render window) there are no plane geometries (the crosshair) being added to the storage model.

A simple context-menu was added in {D726}. Needs to be reworked to allow more actions.

Pixel information has been removed. To add a specific view for pixel information, see T29324: Create view for pixel information.

Pixel information has been removed with {D686}. We discussed that we will open a new task to add a simple pixel value information view as a separate task.

{D722} also belongs to this task but might not be finished this week.

I added another fix to have a simple datanode context menu with a reinit and reset-geometry action for render-window specific initialization.

I created a first working version, based on @s434n's branch (see above). I created an integration branch, made some changes and rebased everything to the latest develop.
Now the following changes, which are already merged into develop, are included, since the integration branch is based on e4d0b1591a17054b4c6792c235aa41345b842cb7:

• T27613: Improve reinit behavior / {D675}
• T26496: [mxn multi widget] Re-initializations reset all render windows / {D708}
• {T26627} / {D714}

Thank you 🙏

Here's the first batch of clean-up action. Needs to be continued!

In T24398#241998, @floca wrote:

Our side or also the CTK part.

Hm, lets put it as known issue and discuss its priority when we plan the spring release.

thank you for looking into that matter.

In T24398#241991, @kislinsk wrote:

I noticed that the whole plugin is a complete mess BTW and urgently needs at least some clean up to see all the potentials for improvements and bug fixes. :/

Our side or also the CTK part.

I added the PR (https://github.com/MITK/MITK/pull/262/) as a differential.

I quickly looked into this using the experimental state of the mxnMultiWidget but I get a Workbench crash. This might be unrelated so I tested something else:
I used the StdMultiWidget, loaded Pic3D but then I used the Render Window Manager to change the Mapper of the axial render window from 2D Mapper to 3D Mapper.
I get the following crash:

Could be the same issue like in T28816: [Segmentation] "New Segmentation" dialog to small

Stefan is right that, from the medical perspective, there is no need for these pixel types. And urgently needed not they are. We can easily convert all the files with strange pixel types to files with 'normal' ones. The issue here is simply from a usability/user experience perspective. It is uncommon to me (and probably other as well) to load an image and then get told the pixel type is not supported