Page MenuHomePhabricator

[worklist] mitk-flow: save changed dicom segmentation not possible
Closed, ResolvedPublic

Description

I created a segmentation with the help of a worklist (dicom). And was able to successfully store it.
When I try to change the segmentation, again with a worklist, I get the following log message:

#18.075# ERROR: No suitable writer found for the current data of type LabelSetImage with extension .dcm
#18.161# ERROR: No suitable writer found for the current data of type LabelSetImage with extension .interim.dcm

The worklist task:

{
    "Image": "1.2.276.0.7230010.3.1.3.17458495.553.1670831890.625556/REF_IMG/1.3.12.2.1107.5.1.4.73104.30000020081307523376400012883.dcm",
    "Segmentation": "1.2.276.0.7230010.3.1.3.17458495.553.1670831890.625556/get-input-data/1.2.276.0.7230010.3.1.4.17458495.553.1670831890.625557.dcm",
    "Result": "1.2.276.0.7230010.3.1.3.17458495.553.1670831890.625556/application-output-dir/result.dcm",
    "Name": "513/04 task 0"
}

Do I have to do something different in the worklist-task, when trying to change an existing segmentation?

Revisions and Commits

rMITK MITK
Restricted Differential Revision
Restricted Differential Revision

Event Timeline

gaoh triaged this task as Normal priority.Dec 12 2022, 10:46 AM
gaoh created this task.

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.

@floca What is the state of DICOM SEG in MITK which I assume is the format of segmentations when saved as "DICOM"? Off the top of my head I seem to remember that it was never fully implemented or did it just affect 3d+t segmentations?

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.

I would propose the following workaround:

  1. Change DICOMQIPropertyHelper::AdoptReferenceDICOMProperty to only set the property value if it does not exist ( so no overwriting if the target property list already has the property). With this I want to prevent already existing DICOM information to be overwritten.
  2. At the task list business logic where the data is (re)loaded: If a segmentation is loaded, add a call of DICOMQIPropertyHelper::DeriveDICOMSourceProperties(inputImage, segmentation). Remark: I would also mark this change as a workaround for T29431 that could be removed as soon as T26953 and alike is fixed.

@kislinsk that should do the trick and allow Hanno to proceed

kislinsk added a revision: Restricted Differential Revision.Thu, Jan 19, 10:28 AM

@gaoh could you verify if the fix work?

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

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

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