Input location is used by the SegmentationTaskList and SegmentationTaskListIO.

After looking at the checklist again, I don't think there is a need to change anything. The checklist specifically only speaks of selecting the line-node once. When following the checklist instructions, everything should work as described.

Pushed new branch to rMITK MITK: feature/T29519-ReduceVerticalSpaceOccupied.

It is indeed two conflicting mechanisms.

@floca I think the issue is that it will probably be better to separately communicate server endpoint and refer to the Study/Series items in the DICOM model hierarchy via UIDs. I think adding support for DICOM should be done as part of the initial design, rather than and afterthought and replacement of file paths by URIs. But that only makes sense if DICOM is important and primary for the use case driving the development. That is why I suggest you guys proceed with your original plan, and we will try to experiment with the DICOM-centric design. But of course I may be wrong. I just think it is more expedient to experiment rather than coordinate the design at the same time as the use cases and requirements are evolving.

In T29160#246278, @fedorov wrote:

I think at this point it probably makes sense for us to explore some dynamic JSON representation for defining the task that is geared towards using DICOM, and if/when it makes sense, we can sync up to exchange thoughts and consider harmonization. The statement of the problem is very dynamic, and it is probably too early to do such coordination now.

@kislinsk @floca thank you for the feedback!

Hi Ralf,
I tried explicitly deleting widget objects but no difference. The destructor of QmitkSingleNodeSelectionWidget ie. QmitkAbstractNodeSelectionWidget::~QmitkAbstractNodeSelectionWidget finishes without issues for every widget present.
It has something to do the MessageDelegates and listeners. I don't know how to explain but I have found a way to "fix" the issue.
When I try to explicitly prevent adding Node Events namely, AddListener & RemoveListener for QmitkSingleNodeSelectionWidget object in the nnUNet tool GUI, the problem of crashing goes away! It works.
That probably means, the DataStorage object is having hanging ghost listeners which causes the crash. (But it doesn't make sense because ~QmitkAbstractNodeSelectionWidget is suppose to remove them explicitly).
My "fix" is in D793 - maybe it rings a bell.

Pushed new branch to rMITK MITK: feature/T29130-nnunet-nodeselector-bugfix.

But it can be used as inspiration indeed. For example, a vectorized, simplified version of the colored organs maybe. See also my idea in the #proj-mitk channel. This could have impact on the grade of simplification/reduction.

No way that this works as an icon.

@wasserth suggested the following image as a starting point:

Please see the build instructions. Long story short: MITK uses a superbuild, meaning it has two build levels. What you see is the outer level, called superbuild. The superbuild downloads, configures, and builds all required third-party libraries (except Qt) automatically. One of the projects of the superbuild is the MITK build itself, the inner level. As soon as the MITK-Configure project was successfully built on superbuild level, you find a populated MITK-build folder in your superbuild folder. From then on you can set it as build directory in CMake to change the configuration of MITK itself, for example, enable plugins and so on...

Which class try to acces an invalid pointer?

I opened an issue regarding an official logo and/or icon: https://github.com/wasserth/TotalSegmentator/issues/98

yes

Not necessary for the upcoming release but we should look into it nevertheless and take care of it.

This context and code artifacts referred in this issue seems obsolete or changes. The issue needs to be rephrased if not closed.

In T29160#246167, @kislinsk wrote:

In T29160#246166, @fedorov wrote:

• l think it will be important to make it possible to work with the inputs defined by DICOM UIDs and available through DICOM endpoints, instead of relying purely on file system. Would this be acceptable for your use cases?

We focused on local file paths so far indeed, driven by our requirements and Kaapana’s way of providing general resource access through local files. URIs are not off the table, though, as long as complexity lies within in the intentional KISS spirit of the file format.

I agree (to both ;). If we extend it (which makes mid term also sense for Kaapana) I would go for URIs and avoid any custom specification for different datasources and protocols. I think it is the minimal invasive and well standardized. DICOM could be covered the via DICOMWeb requests.

In T29160#246166, @fedorov wrote:

• l think it will be important to make it possible to work with the inputs defined by DICOM UIDs and available through DICOM endpoints, instead of relying purely on file system. Would this be acceptable for your use cases?

Thanks. Here are some more comments to start the discussion:

• l think it will be important to make it possible to work with the inputs defined by DICOM UIDs and available through DICOM endpoints, instead of relying purely on file system. Would this be acceptable for your use cases?
• In addition to segmentations, it would be helpful to include an option to perform the review of existing segmentations (e.g., those generated by AI that need to be QA'd by an expert, and where some kind of segmentation may or may not be generated as part of the QA process)
• I think there is potentially common needs between this task and the "MetaDashboard" initiative in kaapana (see https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/MetaDashboard/) - should these two efforts be coordinated? In that regard, the definition of the worklist does not need to be limited to support of the segmentation task (e.g., there are other tasks already considered in the context of the MetaDashboard, such as series type classification, presence of the artifacts.

Pushed new branch to rMITK MITK: feature/T29497-totalseg-subtasks-support.

Or we just forbid parallelization with windows... Parallelization of R in Windows is such a series of workarounds....

Great @wiesenfa! The test with doRNG passed on Windows and Ubuntu!

using doRNG might be the best version should work on any OS

Oh I HATE it!
Could you please try (first installing package "doRNG" https://cran.r-project.org/web/packages/doRNG/index.html ):