Expected Dimensions of DICOM Seg

[opennog]

Hi,

First of all, I'd like to say that I'm a new user of dcmqi. So I might be doing something wrong, however, let me explain the issue I'm having below:

I have a White Matter Lesion Segmentation algorithm and I'd like to convert its outputs, both the segmentation lesion mask and the segmentation lesion labels, to DICOM Seg.

When I convert the lesion mask (which is a mask of 0s and 1s only) the conversion is done successfully, and its properties can be successfully extracted with standard neuroimaging processing tools such us mrtrix or dcm2niix. However, if I do the same with the labels (which range from 0 to 44 in this particular case - one label per lesion), the conversion is also successfully but the aforementioned tools are not able to extract the image properties correctly. For example, mrtrix does not work and dcm2niix assumes there are 11264 slices!!! which correspond to 256 (actual slices) * 44 = 11264.

I know that dcm2niix works pretty well with multiframe DICOM data, so this surprised me. This i why I'd like to ask what should be the expected dimensions of my converted volume?
[192, 256, 11264] or [192. 256, 256, 44]

Thank you in advance.

[fedorov]

@opennog I am glad you already submitted an issue with dcm4niix - this is something for @rordenlab to investigate. DICOM Segmentations are somewhat unusual, since you can have multiple segments (segment corresponding to the unique label value within a segmentation volume) within one SEG object, and each segment will have one or more frames, where frames may or may not be overlapping.

When you export your segmentation into DICOM SEG using dcmqi, the actual number of frames encoded will depend on whether you enabled the --skip flag. If you did, then only the frames corresponding to the non-empty slices of each of the labels will be encoded. Otherwise, every single slice for each of the labels you defined in JSON configuration will be saved as a frame within DICOM SEG. It is usually practical to skip empty slices, since this will significantly reduce the size of the DICOM representation.

In order to reconstruct the geometry of the output segmentation, converter will need to consider geometry of each of the frames stored in DICOM SEG, and take the largest extent covered by the frames.

Note that if you choose to skip empty frames, the geometry of the segmentation may not match the slice extent of the image you are segmenting. I.e., if you image volume contains 100 slices, but your segmentation labels are defined only in slices 10 through 30, the reconstructed segmentation volume will only have 20 slices. You will need to resample that segmentation to the volume of the reconstructed image series if you need to have matching geometry for the downstream processing.

Note that you should be able to use the segimage2itkimage command line tool to convert DICOM SEG to ITK-readable format.

I understand this might be confusing, so please let me know if you have any further questions.