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?

Added a simple check for the dimension. I will have to take a closer look at the 4D (maybe 2D) support in the next weeks unless there are volunteers who can take more care of it.

For the bugfix release the 3d support in general should be enabled again.

Thank you! 👍🏻

Your new branch is directly/indirectly based on releases/2018-04, right? Is it finished with regards to the release / can I merge it into releases/2018-04?

kislinsk edited projects, added MITK; removed MITK (2018-04-2).EditedMon, Mar 11, 9:30 AM

I cherry-picked the two compatible commits (out of three) into the releases/2018.04 branch.

I created a segmentation of Pic3D, however, there is no option to chose DICOM SEG when saving the image. Might be related to the third incompatible commit? Is this really finished as I noticed includes of a cpp file which looks a little bit experimental in that last commit?

The derived segmentation can only be saved as DICOM if the original image is a DICOM.