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().
|Open||None||T25798 Saving segmentations as .dcm (DICOM SEG) does not work|
|Open||None||T25801 DICOM Seg writer doesn't support 4d DICOM images|
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.
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?