Page MenuHomePhabricator

MITK FlowBench v2023.04 - crashes on "Accept segmentation"
Closed, WontfixPublic

Description

I tried the current release MITK FlowBench version v2023.04 (in the previous version it was working) and it crashes, when accepting a segmentation.
It is independent of the image.
I just created a simple task list:

{
    "FileFormat": "MITK Segmentation Task List",
    "Version": 1,
    "Name": "Kaapana Task List",
    "Tasks": [
        {
            "Image": "get-input-data/IM-0001-0331.dcm",
            "Result": "mitk-results/result.dcm",
            "Name": "m2olie_019 task 0"
        }
    ]
}

An executed it with:

/mitk/MitkFlowBench.sh /mitk/tasklist.json

Everything is loaded correctly and works fine, until I want to store a created segmentation:

---------------------------------------------------------------
[10.390] Writing image: /home/hanno/project/mitk/MITK-v2023.04-linux-x86_64/mitk-results/result.dcm
Aborted (core dumped)

Event Timeline

kislinsk added subscribers: floca, kislinsk.

@floca Is this something we are already aware of (saving as .dcm crashes)?

kislinsk edited projects, added Request for Discussion, MITK (v2023.12); removed MITK.
kislinsk moved this task from Backlog to Cycle on the MITK (v2023.12) board.
kislinsk moved this task from Backlog to MITK Meeting on the Request for Discussion board.

@gaoh Since we released MITK v2023.04.2 yesterday specifically addressing a DICOM-SEG issue I kind of got an overview of the overall situation in MITK regarding saving DICOM-SEGs.

In its current experimental state I highly recommend NOT to save segmentations as DICOM-SEG when it isn't an absolute requirement.

There are quite a few annoying strings attached and the data loss that was fixed in MITK v2023.04.2 is just one of them. Loading these segmentations again in MITK will lead to showing wrong/placeholder names for labels, putting each label in its own group and so on... Also it is rather easy to cause a crash when the input DICOM image is not completely standard conform which seems to be the case rather often. Dynamic images are not supported at all... So, the actual crash happening can have quite a few reasons that are not specific to segmentation task lists but to saving DICOM-SEGs in general which will be addressed in future tasks since it also involves contributions to upstream third-party projects.

So I propose to close this task as Wontfix as the issue(s) will be addressed by other DICOM-SEG tasks, okay?

Ok, since this issue made it impossible to use v2023.04 in Kaapaana mitk-flow, I am still on the previous release, where it kind of works?
So I would stay on this previous release until there is a new MITK version addressing these DICOM issues.
For now we are highly dependent on dicoms, so we don't have the option to just store the files in another file format...

@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.

So if you go back to an older version you might not have a crash, but you produce corrupted results if you store multiple label.

For now we are highly dependent on dicoms, so we don't have the option to just store the files in another file format...

Why can't you use in the mitk-flow dag (as a work arround) the converter operator for dcm seg?

@kislinsk Where does the crash originate from?

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.

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?