@ lassoan I would argue that NRRD and NIfTI are very similar from a user perspective, but one core problem with DICOM to NRRD conversion is that NRRD is unable to preserve rescale intercept (0028,1052) and slope (0028,1053) . In contrast, NIfTI has a direct translation in scl_inter and scl_slope.
Consider the typical DICOM storage of CT scans, where the raw data is stored as a 12-bit unsigned integer (0…4095) and the rescale intercept/slope translates this to Hounsfield units:
(0028,0101) US 12 # 2, 1 BitsStored
(0028,1052) DS [-1024] # 6, 1 RescaleIntercept
(0028,1053) DS [1] # 2, 1 RescaleSlope
In this situation, a DICOM-to-NRRD converter must make a difficult decision:
- Keep original data format. In this example values will appear to be 0…4096 rather than -1024…3072.
- Save image data as FLOAT32, requiring twice the disk space (and depending on the viewer, float vs int performance penalties).
- Recognize that in this case both the rescale slope and intercept are integers, so losslessly apply the intensity transform and save data as signed 16-bit integer.
While the final approach is attractive, I do not think it is common. Further, it will not work in situations like MRI-based arterial spin labeling where the slope and intercept values are not integers. Likewise, it will not work when one wants to use NRRD to create a detached header for a DICOM image.
In general, I am an advocate of NRRD, but as the developer of DICOM to NIfTI/NRRD converter (dcm2niix), the lack of a slope/intercept in NRRD keeps me up at night. I am not sure if all users are aware of the consequences of converting to NRRD.