Page MenuHomePhabricator | MITK

Saving segmentations as .dcm (DICOM SEG) does not work
Open, HighPublic


As far as I know this is a known issue. However, it is the default when saving a segmentation from the Data Manager. For now, return Unsupported as confidence level from DICOMSegmentationIO::GetWriterConfidenceLevel().

Event Timeline

kislinsk created this task.Dec 20 2018, 5:44 PM
kislinsk triaged this task as High priority.
kislinsk closed this task as Resolved.EditedDec 20 2018, 5:52 PM
NOTE: I had some trouble when I simply changed the confidence level. Somehow the writer was registered twice and one time it still returned Supported. The debugger said that it couldn't find a matching .cpp file as the obvious choice would differ from the resulting binary. I manually had to delete the IO service DLLs for Multilabel, DicomSegmentation, and DICOMQI. I guess it has something to do with differences between the master branch and the release branch and switching between the branches may result in inconsistencies of the copied service DLLs.
metzger reopened this task as Open.Dec 21 2018, 12:04 PM

Sorry, I missed this task. Maybe we should add a condition to the confidence level check and do not return unsupported in general. I think at the moment most checks are done IN the writer and not before. What was the actual problem?

The problem is that the writer currently isn't able to write anything (at least I was not able to find something that might work). AFAIR, Marco updated DCMQI a few months ago to at least prevent the writer from crashing, which doesn't happen anymore, but the update didn't intent to completely fix the writer.

I think the most correct way of handling this is to create a task for a future realase or bugfix release to fix the writer.

Ok. Is this for the bugfix release? When is the 'deadline' for this?
Still I don't think that's the best way. Maybe we could rank the writer lower or something similar, so that people, who know when they can write DICOM SEGs, could use the writer. I will have a look at the GetWriterConfidenceLevel() checks asap.

Yeah, one could lower the confidence level, but it still would expose a broken writer to the user, so I see no reason to enable it until it is fixed. or do I miss something? How could someone suddenly write DICOM SEGs?

BTW, the confidence level is a bit confusing here as it is set both in the FileIO class seperately for the reader and writer, but changes to them have no effect because theres a general confidence level set as service property in a module activator.

kislinsk removed kislinsk as the assignee of this task.Dec 21 2018, 4:18 PM

Almost forgot: Deadline for the first bugfix release is probably middle of January.

metzger added a comment.EditedDec 21 2018, 5:10 PM

If you load a DICOM image and create a segmentation based on that, you could write a DICOM Seg. For that case, the writer works for me.
Unfortunately not for 4d images and I will report a task for that. T25801

As I said we could use the check condition from write(). See committed branch. Now only if the segmentation is based on a loaded DICOM image the writer appears.

Ah, nice, I see. Testing 3d images was obviously too obvious for me. :D If the 4d case isn't fixed until the bugfix release, we could also check for the dimensionality to decide if the writer supports the image, right?