Problems exporting segmentation as separate Z slices

Hi everybody,

I need some help in exporting segmentations in a way that matches the original data. I searched the forum here and I solved part of the issue, but I can’t move forward.

I have a sequence of DICOM files, each one containing a 512x512 slice of a cardiac CT scan. A segmentation was made from these files with 3DSlicer, resulting in two files, nifti + nrrd. I can visualize everything and it looks good.
Now I’m doing some data analysis and I need the segmentation as a sequence of slices matching the original ones in size, number and z position - what I will do is comparing 2D arrays.

Size (512x512) is not a big problem, I can either add pixels or save DICOM files with the proper size by setting the original volume as reference. The number of slices can also be fixed by adding empty segmentation slices at the beginning and at the end of the sequence.

But alignment along the Z axis seems to be a problem. When I export the segmentation as DICOM and check the Z information, Z spacing is something like 0.39 instead of 0.4 of the original sequence… as a result I can’t add a simple offset to align the two sequences, because I always have misalignments at the beginning or at the end of the sequence.

It looks like my export does not preserve all the properties of the original sequence/volume… what am I understanding or doing wrong? :slight_smile: Any help would be highly appreciated!

I can also provide examples if needed…

When you export a segmentation to labelmap, you can choose a reference volume. It ensures that the geometry (origin, spacing, axis directions, and spacing) exactly matches the reference volume’s geometry.

Do you export the data sets using Slicer’s DICOM exporter?
For the original spacing of 0.4, is the exported spacing something like 0.39 or 0.399999999?

Hi! Thanks for your reply :slight_smile:

The problem appears when, on the Data view, I right-click on the Segmentation and choose “Export to DICOM…”. The spacing when I read back the files is 0.3925. I think I chose the correct volume, because the output changed from cropped to 512x512, as the original dataset.

However, today I did some more search here on the forum, and it seems that by using “Modules -> Converters -> Export to DICOM Series” I get better results… I’m currently converting a few datasets to confirm it. Now the spacing offset is a constant .001 which I think is a more than acceptable effect of roundings.

As a side note, I have the impression that the “Reverse dataset” checkbox does not work, and the first slice of the segmentation export always corresponds to the last slice of the original dataset. I know there are different standards, I thought the checkbox could address this… no problem, I’ll reverse the filenames with a script.
Screenshot from 2020-04-17 18-23-53

Just for completeness, this is the procedure that does not work for me:

The “Create DICOM Series” seems to work and maybe is also be suitable for automation…

Thanks for the update. Note that “Modules -> Converters -> Export to DICOM Series” exports segmentation as CT image volume, not as a DICOM segmentation object. You might be able to use it in some software but it is not the right thing to do.

I understand. In my case it should be fine, I need square images and the corresponding square segmentation masks to feed a neural network.


DICOM format is unnecessarily complex for storing training data for neural networks.

Many people new to this field choose suboptimal formats for storing their training data. A quick overview of what is out there:

  • consumer image file formats (png/jpg/tiff) are too simple, don’t use them for medical image data, as you may end up losing important information due to limited bit depth, unknown slice spacing and axis directions
  • DICOM is complex, it is hard to write and read them correctly, so there is a high chance that your information get misinterpreted
  • research file formats hit a good balance between complexity and feature set: they can store all important information without unnecessary complexity. Within these formats:
    • metatimage (mha, mhd): simple research file format, unfortunately you cannot specify axis kinds, so it is limited to handling 3D data (3D+t, 2D+t, etc. storage is ambiguous)
    • nifti (nii, nii.gz): very specialized and somewhat complex format for neuroimaging, it should only be used for neuroimaging data, where the complexity is actually necessary. I would only recommend NRRD for storing training data for brain (neuroimaging) applications
      -nrrd good general-purpose research file format, it is very simple yet has no significant limitations. I would recommend NRRD for storing training data in general
1 Like

Thanks, I see your point. We’re using DICOM because we’re at the prototyping stage, I thought it was convenient to just use the original CT DICOM files as they are and convert the segmentation masks to the same format. But I see the meaning of using NRRD… I could probably invest some time in converting the dataset :slight_smile:

Using DICOM has very strong, unique advantages, but convenience is not one of them. In medical imaging deep learning workflows you would normally use these formats:

  • DICOM for archival: store your original CT data as is, in DICOM; it also makes sense to store segmentation data as proper DICOM segmentation object, too, especially if you share it with other groups (cross-references help in data integrity)
  • Research file formats (nrrd, nifti) for storing relevant data that you extracted from DICOM files (e.g., extracted images, structure sets, segmentation objects)
  • Numpy arrays (npy, npz) for normalized/augmented data (e.g., after prealigning, resampling, cropping), they can be read/written more efficiently than research file formats and they don’t need to store any metadata (as they are already normalized)

Most medical imaging data sets start at level 2 (research file formats), so you don’t even have the option of storing everything in DICOM. If you are at prototyping level, then you don’t need to worry about DICOM for now, just create a solid process for getting all your data in a convenient research file format.

Later, if things start to get more serious, then DICOM becomes essential. If your are building your own database, then DICOM is good for disciplined, archival-level data storage. You also need DICOM when you connect your software directly to clinical systems, as all your input data will be in DICOM and you need to provide your results in DICOM.

1 Like