I uploaded a fix in D783. Let's see if this will solve the issue also for Ubuntu.

Deleted branch from rMITK MITK: bugfix/T25316-EnableThemedIconsInEagerPlugins.

I tested this on Windows with 4974a335ada8a85d7fba8d313e2efc20acc84b48, which was the latest develop I had, since I recently merged something into develop and couldn't reproduce the error.
Used StdMultiWidget, no other plugins open, no data loaded, only the widget planes available in the data storage.
I tested this with the commit given in the task description and couldn't reproduce the error there as well.

Pushed new branch to rMITK MITK: bugfix/T25316-EnableThemedIconsInEagerPlugins.

In T29432#244945, @kislinsk wrote:

While the original issue is rather easy to resolve by exchanging the class to data->Modified() with a RequestRenderWindowAll() (which is the actual intent anyway according to the comments), more hurdles start to appear that are not as easy to resolve.

The data loading that is now happening immediately, is happening even before the rendering manager has any registered render windows. Any geometry validation of the data against render window geometries is a no-op, and it is kind of okay as it just works. However, when now adding another label in the GUI for example, the Segmentation View again does its data validation and now there ARE render windows with geometries and these do not match the segmentation geometry, resulting in the Segmentation View complaining about a necessary reinit (that is not necessary, yet is technically correct). There are many strategies to resolve this issue, none of them seem easy. The most straight-forward concept at least would be to defer loading of any data until the application is done with initializing its plugins and editors. That would probably require some kind of "ready" event triggered which could be used to load data specificied on the command-line.

Deleted branch from rMITK MITK: feature/T29432-PreloadFirstTask2.

After meeting it is decided that:

1. Label names/classes & their pixel values that are hardcoded in the python codebase will be parsed directly and shown in MITK for 2023.04 release (Ref: https://github.com/wasserth/TotalSegmentator/blob/master/totalsegmentator/map_to_binary.py)
2. Certain subtasks which need multiple nifti file agglomeration (eg. "Body") will not be included in the 2023.04 release.

Deleted branch from rMITK MITK: release/T29488-2023-Week-11.

Pushed new branch to rMITK MITK: release/T29488-2023-Week-11.

Deleted branch from rMITK MITK: bugfix/T29481-FixOddIncludeGuard.

Pushed new branch to rMITK MITK: bugfix/T29481-FixOddIncludeGuard.

I noticed that it only happens in v2022.10 but not in the latest develop so chances are high that it is already fixed but it should be double-checked with the upcoming snapshot installer.

Deleted branch from rMITK MITK: bugfix/T29481-FixAndUnifyIncludeGuards.

Pushed new branch to rMITK MITK: bugfix/T29481-FixAndUnifyIncludeGuards.

Deleted branch from rMITK MITK: bugfix/T29480-RemoveUnusedFiles.

Pushed new branch to rMITK MITK: bugfix/T29480-RemoveUnusedFiles.

Pushed new branch to rMITK MITK: feature/T28578-Test-MxN-installer.

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.

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.

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

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

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

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

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

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

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.

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

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

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 Ralf,