As far as I understand the plugin's purpose it is basically an export of an image as CSV file? And the request is to add it to MITK instead of eMITK? Is there some additional functionality involved or could we just add it as another MIME type for images instead of a dedicated plugin?

Deleted branch from rMITK MITK: feature/T30177-ContourModelSetToSegmentationApp.

Deleted branch from rMITK MITK: feature/T30176-FindTask.

After we have moved to Qt6, we then have QtCharts to our disposal and migrate to that.

After we have moved to Qt6, we then have QtCharts to our disposal and migrate to that.

After we have moved to Qt6, we then have QtCharts to our disposal and migrate to that.

Should be done after(!) we have moved to Qt6 as we then have QtCharts to our disposal and migrate to that.

After we have moved to Qt6, we then have QtCharts to our disposal and migrate to that.

Should be done after(!) we have moved to Qt6 as we then have QtCharts to our disposal and migrate to that.

Should be done after(!) we have moved to Qt6 as we then have QtCharts to our disposal and migrate to that.

Should be done after(!) we have moved to Qt6 as we then have QtCharts to our disposal and migrate to that.

I introduced the doRNG package to ensure reproducibility on Windows.

Pushed new branch to rMITK MITK: feature/T29560-totalseg-label-update.

We want to have:

• a slick minimum Workbench version
• a fuller / bigger version. Exact contents and name still need to be compiled (e.g. Perfusion, Fitting, ...)

After meeting, it was decided to remove the quotes from label names.

MITK v2022.10

The app is now called MitkContoursToImage. By default it outputs classic binary images for each contour set in the input. Use the --format/-f flag (defaults to binary) to change the output format to label or multilabel. The former outputs single-label segmentations for each contour set in the input and the latter outputs a single multi-label segmentation with labels for each contour set. Note that each label will be in its own layer/group to allow for overlapping labels.

Pushed new branch to rMITK MITK: feature/T30177-ContourModelSetToSegmentationApp.

I had a look as well: two voxels is really an edge case, given the current method it would only give a correct result for number of bins == 1 . But setting the number of bins to at most (number of voxels - 1 ) doesn't really help, it fails e.g. for three voxels. In general thinking a bit about it I came to the conclusion that limiting the number of bins (currently it's _minimum_ 10) would still not yield a correct median.

So I can store files as nrrd and then use the mitkfileconverter to convert them to dcm? And this is better, then directly storeing the files as dcm?

Multiple reasons depending on the reference data. Mainly related to non-conforming images or at least images that are recognized as such by us or our third-party deps. Other reasons include 4-d images as you already mentioned. We talked about it a few days ago and this part of MITK and our third-party deps needs a little bit of love and affection as it seems.

@kislinsk Where does the crash originate from?

@gaoh Maybe you got it wrong. Saving DICOM seg is broken like always. The there is no version before v2023.04.02 that could store multi lable segmentations correctly and 4D will always crash. If you find a earlier version that does not crash on your data, then it is highliy likely to a change in DCMTK over time.