The Label Suggestions JSON file format mentioned above to specify a list of suggested names and optional colors for new labels is as follows:

The first version of the file format used in T29159 is as follows:

Done in T29159.

The feature is ready for demonstration.

@s434n If it is OK for you, I would take over as I think the tools need a further refactoring. They still have to much redundancy that could be avoided.

@j762e If you work in the task (which would be great ;), please claim it.

In newer versions of ITK the GrowCut.remote.cmake is added by default to Remote Modules (eg. https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/Remote).
Our version of ITK (https://www.mitk.org/download/thirdparty/) doesn't include that yet.
rMITKc94224c7fe81 is a "workaround" to still add the Remote Module without changing the present version of ITK on our server and might be reverted in future.

Pushed new branch to rMITK MITK: feature/T28851-AddITKGrowCutTool.

If a relaxed check (see above) is not sufficient, we should discuss it in the MITK meeting. But I think a more sound/clean approach is, that we have a way who interaction can assess/express if a geometry is appropriated for them and render windows react appropriatly (e.g. showing a overlay message if you enter the render window "Not able to interact due to wrong...")).

In T28464#239595, @floca wrote:

@s434n Have claimed it for finding the error* (good job by the way). Then you can unclaim it now.
Or will you work on that issue further?

It is an unfinished feature. It was planed to also support scaling. But back then I hadn't enough time so I made it invisible. And as nobody needed it till then, its prio was not raised and it was not implemented.

@s434n Have claimed it for finding the error* (good job by the way). Then you can unclaim it now.
Or will you work on that issue further?

We can simply remove the geometry-comparison so that the segmentation tools are enabled, regardless of the geometry-alignment.

Removing makes no sense (see below), but may be relaxing. For what the Segmentation View wants you need no equal geometries you just have to ensure that the geometries are "grid aligned". So what we realy need is the IsSubGeometry() (may be even without checking the size of the geometry (so without 1016-1067)). Have you checked it with such a check?

Pushed new branch to rMITK MITK: feature/T29202-nnunet-download-model-doku.

The first step of the GSP process is cleared: @j806e and @m700r managed to adapt the code, fix some path related bugs, install pytorch for different types of GPUs and train the the polyp detection models.

Warning messages when there are missing values in the data were reviewed as below:

In case the number is already serialized as floating point instead of an integer it is probably an i18n issue regarding the difference of the decimal point . and , in English and German locales. We had these issues quite often in the past and the solution to such issues is to enforce the neutral locale while serializing/deserializing on the streams. Just search for "imbue" in all of MITK's .cpp files for examples. There's also the LocaleSwitch class but I think I can remember that there's an issue with it. Still both solutions can be found many times in MITK.

Deleted branch from rMITK MITK: bugfix/T28285-Windows-UTF-8.

I worked on this again and found the following:

• with the different data that I used for testing the boundingboxes of the node geometry and the world geometry were always and only equal, if the render window used for the world geometry was either set to "3d" or "axial"
• therefore, using the active render window (instead of the hard-coded "3d"-render window) only works if the active window has the view direction "axial" or "original"
• this is true for the mxnMultiWidget and the StdMultiWidget (as the StdMultiWidget also sets an "active render window").

Hey everyone,

I would like to discuss if we want to tackle this problem. It is related to T27613, which is still open.

Hi Nil. No update yet. @r948e , do you think you could look into this?

Hi Peter,

I like the results when the scales library is used! However, when we find a way to bring back the confidence intervals, also @wiesenfa's latest solution can be used.

Pushed new branch to rMITK MITK: feature/T29159-SegmentationTasks.

I took another look at this issue, together with @s434n. Another difference we spotted was the used Qt Version. Locally I'm building with Qt 5.12.10, but the version by Nikolas uses Qt 5.12.11. I changed this locally but still my local MITK-XNAT does not establish a connection to E230-xnat.

Deleted branch from rMITK MITK: bugfix/T29082-FixXMLLogging.