Pushed new branch to rMITK MITK: feature/T29468-totalsegmentator-install.

Deleted branch from rMITK MITK: feature/T29468-total-segmentator-install.

Pushed new branch to rMITK MITK: feature/T29468-total-segmentator-install.

Pushed new branch to rMITK MITK: bugfix/T29473-FixUnitTests.

Pushed new branch to rMITK MITK: feature/T29463-totalsegmentator-doku.

Deleted branch from rMITK MITK: feature/T27319-multilabelInterpolation.

Deleted branch from rMITK MITK: feature/T27319-IntegrationBranch.

Pushed new branch to rMITK MITK: feature/T27319-IntegrationBranch.

From a first glimpse it really needs to be continued before merging. Can't make much sense right now out of mitk::StoreSCPLauncherBuilder in parallel to QmitkStoreSCPLauncher::Params. Have to take a closer look.

Deleted branch from rMITK MITK: feature/T29445-MoveSegmentationTaskListWidgetToModules.

Pushed new branch to rMITK MITK: feature/T29445-MoveSegmentationTaskListWidgetToModules.

Should we integrate that in develop? Or any reason to wait?

Found my changes in T29317. :)

I see, I then should probably blow the dust off of the MacBook in my drawer and start to suffer as well. :) / :(

Deleted branch from rMITK MITK: bugfix/T29471-UpdateAboutDialog.

Pushed new branch to rMITK MITK: bugfix/T29471-UpdateAboutDialog.

Hi Stefan,

Hi André, does it freeze for you when scanning the MITK-Data/3D+t-Heart directory? I try to narrow it down but this directory works for me for example.

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

I implemented Manuel's suggestions in branch hotfix/T29361-EnsureReproducibilityWithParallelBootstrapping and added corresponding unit tests to test-bootstrap.R.

Deleted branch from rMITK MITK: bugfix/T29470-FixPluginManuals.

Pushed new branch to rMITK MITK: bugfix/T29470-FixPluginManuals.

Deleted branch from rMITK MITK: feature/T29297-Use-selection-widgets-in-render-window-utility.

Hi Ralf,

After discussion, it's decided that out of the abovementioned "advanced" flags, only --fast will be implemented along with GPU selection.
The --statistics flag seems to bring to some value & it's inclusion was separately discussed here: T29465

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