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,

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.

@gaoh / @kislinsk would that integration/workflow something for the MIC meeting pitch?

🎉

thanks again, for solving this issue! So in the current kaapana develop the tasklist feature is now integrated!

Status: Added quite a few papers up until 2020 thanks to a currated list of papers from @floca. For the past two years we now need to look out for papers first.

@gaoh I triggered the build of a new Flowbench installer in our CI. Will be ready later today and automatically uploaded. Commit hash: 122321bb.

@gaoh could you verify if the fix work?

Pushed new branch to rMITK MITK: feature/T29432-PreloadFirstTask2.

Original issue resolved, raising priority and leaving open to discuss consequences in the next MITK meeting.

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

Pushed new branch to rMITK MITK: feature/T29432-PreloadFirstTask.

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.

Status: Currently I add 10 MITK-related papers per day to our publications page. Ongoing...

Thanks Ralf!

Describe problem has the same root then T26953. But I think for this task here we can have a work around, so that Hanno does not need to wait until the DICOM Seg thing is fixed.

We see and feel you. Considering the circumstances that Ralf mentioned (it's basically an ITK issue/contribution) I would anyway go for a Won't Fix here on our MITK side for now, until ITK provides the functionalities for such data types. Okay? :)

Created an example in this pull request: https://github.com/MITK/MITK/pull/271

Somehow related:

• T24319: Provide filtering techniques for interaction events
• T24274: Globally accesible synchronization handler

Related: T13465: Two 3D RenderWindows at the same time interfere with each other.

In T24398#244802, @floca wrote:

Have you pushed your clean ups? Not that your efforts get lost. 😉

In T24398#242008, @kislinsk wrote:

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.

Only looked into our side so far. I'll create a separate task and push my clean-up that I already did so far.

Without a data sample we are not able to reproduce this issue. Can you upload one of these nrrd files? Please make sure that the data does not contain any personal information. You can also restrict access to uploaded files to certain users like me.

Unfortunately, it is all nrrd files. I updated my nvidia drivers and it seems to have improved slightly in that it doesn't crash within moments of loading a base nrrd file, but after I create, save and remove a segmentation nrrd, MITK Workbench crashes when I try to reload (open) the segmentation nrrd.