data type conversion in PET dicom images

Our group are using PET images to study dopamine receptors with AFNI. The receptors are highly concentrated in striatum; we usually see strong signals (values) in the entire region of striatum. In the first step of our analyses, we convert dicom files to AFNI files. However, I noticed that sometime there appear a few voxels with extremely low values in this hot region (striatum). These extreme values produce a lot of troubles in the downstream analyses. This problem happens in a quite number of subjects in our study.
In the attached picture, the voxel at crosshair has a value of 63, which is extremely lower than the surrounding voxels with values about 30000. The voxels with extremely low values are those black dots within the white region of striatum in the picture. I have also converted my dicom files in SPM and got a value of 65597 in the same voxel (I understand the coordinates are different in RAI and LPI spaces). But I have got similar values in most of the other voxels in the striatum comparing AFNI to SPM.
I suspect that it may be related to the format of data storage in computer. During conversion, I have to run “ step(a) a + step(-a)(a+65536)” to convert negative values.
Do you have any idea of what is going on? Any suggestion is appreciated.
Best,
Juen

Use this command to convert dicom to AFNI file:
Dimon -infile-patter ‘*.dcm’ -dicom-org -GERT_Reco -Quit
3dcalc -a filename “ step(a) a + step(-a)(a+65536)” -datum float

I have just tried to convert dicom to nii in spm and then to afni. The problem is gone if I do this way. But I don’t know too much about spm and can n’t handle data files in batches in SPM.

Another thing I don’t understand is that the dicom headers says Bits stored = unsigned, length = 2, value=16. Does it mean the max value = 2^16=65536. If it is true, how come does SPM give a voxel value of 65597 which is greater than the max value. Is it related to “length =2”? But this 65597 does make sense to me.

information on data type from dicom header
(Group,Element) TAG Description VR VM Length Value
(0028,0100) Bits Allocated US 1 2 16
(0028,0101) Bits Stored US 1 2 16
(0028,0102) High Bit US 1 2 15
operation system and hardware:
Red Hat Enterprise Linux Server 6.6
Kernel Linux 2.6.32-504.el6.x86_64
Processor: Intel Xeon CPU X5482@3.2GHz

FDR014Temp.jpg

This may be an undetected byte swapping problem. I would recommend comparing the Dimon output with dcm2niix_afni.

Thanks Daniel! It does seem a data swapping problem. The output from dcm2niix_afni does not have extreme low numbers in the hot spot. However, I have trouble running this command. It gives the following error message:
Dcm2niix_afni -o ./ ./dicom_dir
Found 621 DICOM files
Error: Instance number (0020, 0013) not found: ./dicom_dir
1 images have identical time, series, acquisition and image values. DUPLICATES REMOVED.
Convert 620 DICOM as ./outputfilename (256256310*2)

My dicom files are 4D with three time points, each time point has 207 slices. The output somehow contains only two time points (2 blocks) and each block contains one and a half brain images.

I have been looking up in the help document, and couldn’t find an appropriate parameter to correct this issue.

It looks to me like the shorts might be unsigned. Try adding -ushort2float to the Dimon command.

  • rick

Hi Rick,
I have tried -ushort2float last night. It didn’t work. It looks like this parameter just do the swapping with the expression “ step(a) a + step(-a)(a+65536)”. The output produced by Dimon has a range of 0 – 65229. However, the outputs produced by dcm2niix_afni or SPM has a range of 0 – 94914.53. Note that 94914 is much greater than 65536 (the max value of 16 bit short).
I have noticed a voxel with a value of 63 from Dimon, but with a value of 65598 from SPM. Somehow, the difference (65598 – 63 = 65535 = 2^16-1) is almost the max value of 16 bit short.
The dicom header says unsigned short with length =2. Something is fishy here. It seems to me that Dimon only takes 16 bits, while dcm2niix_afni and SPM take 32 bits.

If the header says “unsigned short” that would match using -ushort2float (indeed, that step() type of operation is exactly what it does, it converts a signed short to an unsigned short). Your initial post suggested that you were happy with that.

But a value of 94914 is indeed not possible with short, signed or unsigned, except that perhaps there is a scalar being applied. If that is what dcm2niix is making, an internal scalar (from the DICOM header) seems likely.

Did Dimon/to3d output any message about possible scaling?

Indeed, even 65597 is not possible, as you note. Is SPM doing any resampling of the data?

It is difficult to say exactly what should be done, particularly since we do not have the data. If I had to guess, it would be that there is indeed some scalar that Dimon/to3d was not told or did not know to apply, but dcm2niix is doing so. If that is true, the ratio of those outputs should be constant (however dcm2niix tends to reorient the data, which would need to be matched to test).

  • rick