Small doubt. I have a DICOM series of a T1 scan. I converted this sequence to nifti with “dcm2niix” from command line and now when I overlap both the original T1 dcm and the T1.nii on Slicer I noticed two weird things:
the intensities were rescaled. More specifically, when hovering over the two superimposed volumes with the mouse, the nifti stack has intensities which are from 2-fold up to 10-fold bigger than the original dicom stack.
the z-axis is inverted: while the z-axis value increases for the dcm (e.g. from inferior to superior), it decreases for the nifti (and vice-versa).
I though this was somehow related to the dcm2niix conversion, but then I tried opening the two same stacks (dcm and nii) in fsleyes and the two issues don’t happen (i.e. the intensities are the same and the z-axes are non inverted).
Which dcm2niix version do you use? Can you share an example data set or at least printout of the header?
Does the image load correctly if you load it with DICOM module? (you can import a DICOM series by drag-and-dropping the file folder to the Slicer application window)
@Chris_Rorden Do you have any ideas or suggestions how this issue could be investigated?
Thanks, the example data was very useful.
First of all, the DICOM files contained double-precision floating-point voxels. This is highly unusual for MRI volumes. What software generated this DICOM series?
This is a rather old version. You may try with latest dcm2niix.
@Chris_Rorden Could you check if rescaling of image intensities is correct? Both Slicer and ITK-Snap reports image intensities about 5x lower, so there seems to be an inconsistency between ITK and dcm2niix.
Yes, it looks like a GUI glitch. Please try latest Slicer Preview Release.
I don’t see any issues with image geometry. Images appear the same way. Voxel IJK coordinates are application-specific: it is valid to map a voxel coordinate system axis to any patient coordinate system (LPS, RAS, …) axis and direction.
DICOM images tend like this one store each voxel as a 16-bit integer. This is usually converted into a floating point value using the public tags rescale intercept (0028,1052) and rescale slope (0028,1053). However, this scan comes from a Philips scanner, and Philips introduces several alternative scaling factors. Therefore, most Philips scans can be converted as “Display” value (D) or precise floating point (I refer to these as P, but PAR files refer to these as FP):
The relevant DICOM tags are RS = rescale slope (0028,1053) RI = rescale intercept (0028,1052) SS = scale slope (2005,100E) RealWorldIntercept = (0040,9224) Real World Slope = (0040,9225) The transformation formulas are: R = raw value, P = precise value, D = displayed value D = R * RS + RI P = D/(RS * SS),
For more details read this. Since this is a T1, intensities are relative, so it does not matter which method you use. However, these multiple scaling factors have caused a lot of confusion, in particular with ASL, where different tools expect different values. This explains why dcm2niix reports
Philips Scaling Values RS:RI:SS = 4.65714:0:0.044161 (see PMC3998685)
You can change dcm2niix’s conversion behaviour using the ‘-p’ argument
-p : Philips precise float (not display) scaling (y/n, default y)
I want to emphasise this is not a limitation in dcm2niix. Rather, Philips has invented their own parameters that do not conform to the DICOM standard.
@Chris_Rorden Thanks a lot for the detailed and very informative explanation. To avoid all kinds of issues, it would be nice if we could harmonize default rescaling behavior among commonly used DICOM image readers (dcm2niix, ITK, vtkDICOM). Do you think current rescaling behavior in ITK’s DICOM reader is good as a default or it should use some of the alternatives instead?
@lassoan at the moment there is no consensus among the groups who generate ASL tools. Therefore, hard to give guidance regarding what the solution would be. Mathematically, there could in theory be situations where you can not generate store the precise value in a NIfTI or NRRD style pair of intercepts and slopes, so you would have to convert the raw data to float to preserve these values. Adding to this, it is possible that Philips could store different coefficients for the “RealWorld” values than the precise values, so one need to consider what to do if you have a different NIfTI/NRRD scl_slope/scl_inter for the Precise versus RealWorld values. For GitHub, I have usually trusted @drmclem’s guidance (as he works at Philips and has encyclopaedic knowledge). My current solution is to use Precise values by default, provide the option to use the Display values, report original coefficients in the BIDS sidecar, and report discrepancies between solutions in the command line during conversion. @fedorov may also have thoughts on this.
I also note the development branch of dcm2niix provides clearer notes on these matters than the current stable release.
You should be aware that FSLeyes includes dcm2niix and uses it for DICOM file imports. Therefore, the fact that FSLeyes agrees with command line usage of dcm2niix should not be used as evidence that this is the right way to do things: these are not independent tests.
One looming concern for Philips compatibility is not only can the image specify three different scaling factors (display, precise, real world), but also that a separate intensity scaling factor can be applied to each and every slice of a volume. While this is legal DICOM, neither NIfTI nor NRRD can support this, so I assume converters will need to store voxels as 32-bit floats instead of 16-bit integers to represent these datasets.
