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.

Without any extra preferences, it's as easy as adding the line this->LoadNextUnfinishedTask(); at the end of the OnTaskListChanged() method.

Deleted branch from rMITK MITK: bugfix/T29434-CleanUpPrefPtrAntiPattern.

Thanks for reporting. We are not aware of any crash like this with valid nrrd files. Since ITK snap crashes as well it could be a strong indicator that the crash is happening in the ITK reader that we use as well. It could be probably related to a corrupt nrrd file, or, in case it is a huge file, it could be simply related to running out of memory. Anyway, without the data we are not able to reproduce this issue.

Pushed new branch to rMITK MITK: bugfix/T29434-CleanUpPrefPtrAntiPattern.

The hash above doesn't seem to be auto-linked. So here it is: rMITKa73e482c0387: moved labelset-related classes out from core

A big leap into the Python direction would be to finally resolve T27923: Integrate possibility to execute Python Code in MITK , which is complete for a while now but we weren't able to figure out why it fails on Ubuntu build clients. Since the ITK v5 upgrade, we also need to adjust a little more I guess.

Task lists don't do anything special regarding saving/loading data. So in theory, this bug should be reproducible by regular loading and saving via the menu in the Workbench?
However, task lists are prone to expose existing bugs related to repeated saving/loading of data. We indeed noticed another bug in this direction with .nrrd files, which were erroneous when loaded a second time in certain situations. The reason was faulty handling of properties: T29274: Label Loss on repeatedly loaded and saved segmentations.

Reading your other task regarding mitkscene files I wonder if it has something to to with attaching the level window property to the BaseData property list instead of the DataNode property list. In principle, the level window should be attached to the latter one as it is an "appearance" property and not something instrinsic to the data. A few years ago we changed the way properties are queried and when a property is not present in a DataNode property list, the Base Data property list is queried as fallback. Maybe it is not fully functional for level windows as it could be that the code somehow relies on / assumes that the properties are located in the DataNode property list.

Not sure if I fully understand what is going on here but the difference is that in your first example you have DataNode properties and in your second example you have BaseData properties, right? Let's talk about it in our group 5 meeting today. :)

@a178n I added cpp-httplib as dependency to MITK in the branch mentioned above so you can easily experiment with it. For details, see rMITKf88e3d05aeb0: Add cpp-httplib as optional dependency.

Pushed new branch to rMITK MITK: feature/T29421-httplib.

After a meeting with Ralf and Stefan (30.11.2022), the header-only library cpp-httplib (GitHub: https://github.com/yhirose/cpp-httplib), was chosen as a promising alternative. The library seems the most popular in the GitHub community compared to Pistache, the second favourite library from the list.
Hands-on efforts to build server and client calls will be undertaken to test further suitability.

The literature survey searching for alternatives is summarized here: https://hub.dkfz.de/s/qsEgaWybwiWcfYN

The plugin generator has been removed for now. Step 9 should be redesigned if the plugin generator was the blocker.