Hello,
I was trying to convert the nifti data to the dicom series. I figure out myself how to use the GUI of 3d slicer to export the loaded volume to dicom series. However, there are some problems in the output.
1. the orientation is not correct. I reload the exported dicom series to 3d slicer to check. I found the “IJK to RAS direction Matrix” and the “image origin” is not the same as the volume I load from original nifti.
2. the pixel values are not the same between the exported dicoms and original nifti. there seem to be a small value shift., however, the two image can stll overlap with each other.
the problems are illustrated in the figures. Can anybody help ?
The 00003_xxxxxxx is the original nifti volume.
the unnamed_series is the exported dicom volume
Slicer guarantees that the same voxels will be at the same physical position in the saved image as the original image. However, there are many equivalent representations of the same image in the same physical space (e.g., depending on which corner of the image is chosen as the origin), and it is up to the image reader/writer classes and underlying libraries (e.g., ITK, VTK) to decide which one to choose.
The screenshots above show that everything is correct. For example image origin is relocated in accordance with the origin’s physical position:
1009.5 - 1.5 * (545-1) = 193.5
Software applications that ignore the image geometry (image origin, spacing, axis directions) need to be improved to use the image geometry if physical position, orientation, or size matters for them. If an application just wants to get images and segmentations with matching voxels (for example, to do some simple operations that do not require awareness of the image geometry) then you can export both the master volume and segmentation. In this case the voxel coordinates will match (not just the physical position of the voxels). You can also choose to match any other volume’s geometry, if you export a segmentation using “Segmentations” module’s “Export to files” section and set the image that you want to match as “Reference volume”.
Thanks so much Andras,
How about the small value shift, the pixel values (SUV) are not the same between the exported dicoms and original nifti. I think may be it is because of the datatype rounding, But I don’t have any clue how to solve this.
Until relatively recently, DICOM images could only store integer voxel values. It is possible that the Slicer DICOM exporter does not support floating-point voxel values yet, so some rounding errors are possible. @pieper have you experienced such issue with PET images?
Right, there’s no support for floating point in traditional dicom images, only in the somewhat new PM modality (parametric maps). For pet typically people use the rescale slope / intercept tags to preserve dynamic range and that’s probably what happened here and there was some loss coming back to float.
It probably doesn’t apply here, but note that many dicom PET studies use a different slope/intercept on each slice, but in ITK (hence Slicer) these are all normalized across the volume to the data type and that can be a bit lossy.