I see no value currently, as we have our own statistic backend/view.

Discussion result:
A pragmatic solution would be to get the label names from the qTable as late as possible i.e when the results are returned for the Preview.

How about something like this but in the Preview labels list? Once confirmed, this tail end info will can be pruned and only Label names are transferred.

Pushed new branch to rMITK MITK: feature/T29458-totalsegmentator-advanced.

4. The install instruction pip install TotalSegmentator installed Pytorch CPU version on Windows eventhough there is Nvidia GPU and Cuda drivers available. Not sure this is problem of TotalSegmentator dependency specification or a general pip on Windows issue. Anyway, I had to manually uninstall pytorch cpu version and install again with the cuda supported package.

3. No explicit CPU only inferencing possible. Currently, whether or not the inferencing would run on cpu or gpu is decided by the installation of pytorch in the virtual environment. This might not be enough for MITK tool stability guarantee across all user machines.

2. The installation and run command documentation is not working exactly as per documentation on Windows.

The run command TotalSegmentator -i ct.nii.gz -o segmentations doesn't seem to work because the install instruction pip install TotalSegmentator is not creating TotalSegmentator.exe file inside the ~\venv\Scirpts\ location.
Instead, the pip installation merely keeps a python file. Hence, the correct invocation command would then be python ~\venv\Scirpts\TotalSegmentator -i ct.nii.gz -o segmentations.

1. Output segmentation nifti file comes without any label-pixel metadata eg. in json format , eventhough its known until the last moment before writing it out. Ref. T29461

Hi Ralf,
I did some digging into the TotalSegmentator python code.
So yes, (I believe) label names/classes & their pixel values are hardcoded in the python codebase. Ref: https://github.com/wasserth/TotalSegmentator/blob/master/totalsegmentator/map_to_binary.py
I couldn't find any documentational guarantee for it. Maybe we can double check on it. But the statistics generation (--statistics flag) uses this map to calculate volume & intensity of each label. So it's a safe assumption.

GDCM 3.0.11 introduced a quickfic/hack to handle that correctly. (At least for the test data it works now.)

for "ii" the developments of T29392 could be of help (if we also implement a reader of this kind). But we would still need to generate the meta info file

Pushed new branch to rMITK MITK: feature/T29457-totalsegmentator-basic.

I think we should post pone that for now. And revisit if we have a concrete use case /user request

@j562r wrote in Slack:

We are currently revising the first segmentations which we got by our medical partners using MITK and noticed some common flaws in the segmentations which would be nice if the tool could capture it. More precisely, would it be possible to apply some basic checks on segmentations which are considered "Done". I am thinking of:

• No unused labels
• No empty layers
• All pixels annotated

Would be enough if this is just shown somewhere so that we can easily avoid simple errors. For the latter ("all pixels annotated"), it would also be cool if we could highlight the non-annotated pixels as they are sometimes hard to spot.

I tried today to move everything from MitkMultilabel into MitkSegmentation but it generates some dependency cycles issues like for modules that sit in between MitkMultilabel and MitkSegmentation.

In the meeting it was decided that a decision regarding whether or not to replace or add labels will be still in RFD.
Decision will be later on after further discussion with the group, in conjunction with Ralf's planned changes in the tool API classes.

We decided that it is a nice and maybe necessary feature so we want to encode it somehow.

Hi spectators! 👋

That ist not a good solution (as far as I can see it) i.a. due to other constraints. Lets discuss this topic in the next meeting.

Hi Ralf,

the default implementation is currently to not overwrite label information if already present in the segmentation image only copy labels from the preview that do not exist.

Hi Ralf,

I don't think it is necessarily a bug, but rather unintuitive how it works. The recentering is not triggered by the clicking of a node, but via changes in the selection. One can also do things like select multiple lines (on different slices), then deselect one, and the view recenters to one of the still selected nodes.
For me, it would feel more intuitive if the view just recenters every time a node is clicked, regardless of the selection. But there is no bug apparent to me here.

I think you found already pretty many issues. That is far enough to trigger a conversation with the Monai label team, don't you think?

4. Monai label response JSON vs segmentation image mask labels:

After a segmentation is processed, the response JSON, e.g.

Hi Ralf,