High negative values adjacent to high positive values after DICOM to Nifti conversion

[ahafri]

When converting from DICOM to Nifti using dcm2niix, I have an issue where very high values (above 32767, or 2^15) become high negative values. So in image terms, very bright voxels may surround a very dark voxel:

I also had this issue with AFNI's to3d conversion tool (to3d -time:zt etc.) so I switched to Xiangrui Li's dicm2nii Matlab toolbox which fixed the issue. But I had other issues with that (some DICOM series were failing to convert), so I then switched to dcm2niix.

But the problem that I had with AFNI seems to also happen with dcm2niix. I think dcm2niix is having issues with reading the data as unsigned 16-bit integers, so is reading it as a signed 16-bit integer instead. This would be consistent with the high values above 2^15 then becoming high negative values, I think.

Of note, using the new -l y flag seems to fix this problem (lossless scaling of 16-bit images, issue #198). That is, it gives the same exact results as Xiangrui Li's dicm2nii Matlab toolbox (no high negatives adjacent to high positives).

I'm wondering if something is wrong with my images, or with how I'm using dcm2niix. I can share the DICOM series if it would help. Thanks!

(By the way, adding the -ushort2float flag should fix this in AFNI's to3d; see https://afni.nimh.nih.gov/afni/community/board/read.php?1,155250,155250).

[neurolabusc]

If you can send me your images I can investigate this further. However, my suspicion is that this reflects a visualization artifact of an old version of fslview (which is now deprecated). To test this, try using a modern viewing tool like MRIcroGL or fsleyes. When the NIfTI format was created in 2003 they extended the older Analyze format - one extension was the inclusion of 16-bit unsigned integers. However, until very recently MRI DICOMs were only reconstructed with 12 bit precision. If you use modern NIfTI compliant software it should support this datatype. This explains why ushort2float works.

[neurolabusc]

Thanks for helping me troubleshoot this. This was a bug introduced (by me) on 5 July 2018 and fixed on 16 July 2016. The issue does not exist in the stable release or the current master branch. Historically, I have treated the master branch as being code that seems good to me but has not been vetted by the community, where the stable releases are the major milestones. This is not obvious to users who download the repository. To avoid confusion in the future I will try to increment create a development branch after each major version (so the master branch will be the last stable version) and make sure the version name clearly denotes developmental status.