Dimon call outputting one run as float, rather than short

AFNI Message Board
1

I use the Dimon call to transfer my dicoms to nifti format, on which I run the afni_proc.py.

For one subject, one of the runs seems to have been output as a float, rather than short.

I realised this because the proc.py output gives me the following warning:


** WARNING: File all_runs.SL_33+tlrc.HEAD has mixed-type sub-bricks.

and if I look at the 3dinfo with the -verb option, I get an output like:


-- At sub-brick #0 'MB_1_33.nii.gz[2]' datum type is short:            0 to         32767 [internal]
                                            [*   0.00515891]             0 to       169.042 [scaled]

for all other sub-bricks, but


-- At sub-brick #744 'MB_5_33.nii.gz[2]' datum type is float:            0 to       133.795

for all sub-bricks in the relevant run (run 5, in this case).

This seems to only have happened with this one run and this one subject, using the same script I use for all subjects. Why might this be happening?

2

That is peculiar. Can you back up and show the
call (and text output) for Dimon? If you would rather
not post it, please send me email.

The one case where shorts can be converted to
floats is unsigned shorts (that exceed 2^15). AFNI
does not support that format directly.

  • rick
3

The relevant Dimon call is (usually run with the -quiet flag, but taken off to get the output here)


Dimon -dicom_org -quit -use_obl_origin -gert_create_dataset -gert_to3d_prefix "MB_5_33.nii.gz" -infile_pattern "7_MB*/*"

The output I get is as follows (the warnings I get about obliquity happen on all my datasets in the project, I believe because I am scanning at AC-PC - 20°, to minimise dropout in temporal regions). The warnings about the unsigned 16-bit seem to be where the problem is, but my understanding ends there:


Dimon version 4.22 (December 10, 2017) running, use <ctrl-c> to quit...

-- scanning for first volume
++ Data detected to be oblique
*+ WARNING: Slice-based center is different from mosaic center
*+ WARNING: Origin computation of obliquity may be incorrect
Mosaic Center     :   4.91142e-05       19.3652       42.8352
Slice-based Center:       1.21202       20.5227       42.4169

-- Siemens timing (51 entries): 0.000 0.785 0.088 0.873 0.175 0.960 0.263 1.045 0.350 1.133 0.438 1.220 0.523 1.308 0.610 1.395 0.698 0.000 0.785 0.088 0.873 0.175 0.960 0.263 1.045 0.350 1.133 0.438 1.220 0.523 1.308 0.610 1.395 0.698 0.000 0.785 0.088 0.873 0.175 0.960 0.263 1.045 0.350 1.133 0.438 1.220 0.523 1.308 0.610 1.395 0.698
*+ WARNING: DICOM file 7_MB.../CA58C62A:
  --> unsigned 16-bit; AFNI stores as signed; 1 pixels < 0
  --> consider 'to3d -ushort2float', if not already being applied

-- first volume found (1 slices)
-- scanning for additional volumes...
-- run 7: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 

final run statistics:
    volume info     :
        slices      : 1
        z_first     : 15.99
        z_last      : 15.99
        z_delta     : 2.5
        oblique     : yes
        mos_nslices : 51 (DICOM mosaic)

    run #   7 : volumes = 188, first file (#0) = 7_MB.../ECDB27D6

++ writing dimon file list to dimon.files.run.007
++ oblique data: applying to3d -oblique_origin
** warning, have signed short overflow to unsigned,
   applying -ushort2float in GERT_Reco to3d command

set OutlierCheck = 
to3d -prefix MB_5_33.nii.gz -time:zt 51 188 1.5sec FROM_IMAGE -ushort2float -oblique_origin -@
++ to3d: AFNI version=AFNI_18.0.22 (Feb 26 2018) [64-bit]
++ Authored by: RW Cox
++ It is best to use to3d via the Dimon program.
++ Counting images:  total=9588 2D slices

++ DICOM NOTICE: 8x8 Siemens Mosaic of 51 78x78 images in file 7_MB.../ECDB27D6
++ Data detected to be oblique
*+ WARNING: DICOM file 7_MB.../ECDB27D6:
  --> unsigned 16-bit; AFNI stores as signed; 1 pixels < 0
  --> consider 'to3d -ushort2float', if not already being applied
++ Each 2D slice is 78 X 78 pixels
++ Voxel dimensions: 2.4615 X 2.4615 X 2.5000 mm
++ Reading images: 
++ DICOM NOTICE: 8x8 Siemens Mosaic of 51 78x78 images in file 7_MB.../DD863E7B
..........................................
++ Number of non-float slices converted to floats = 9588
++ Number of overflow shorts converted to floats = 3
*+ WARNING: Slice-based center is different from mosaic center
*+ WARNING: Origin computation of obliquity may be incorrect
Mosaic Center     :   4.91142e-05       19.3652       42.8352
Slice-based Center:       1.21202       20.5227       42.4169
++ Command line TR=1.5s ; Images TR=1.5s
-- using Siemens slice timing (51) : 0.000 0.785 0.088 0.873 0.175 0.960 0.263 1.045 0.350 1.133 0.438 1.220 0.523 1.308 0.610 1.395 0.698 0.000 0.785 0.088 0.873 0.175 0.960 0.263 1.045 0.350 1.133 0.438 1.220 0.523 1.308 0.610 1.395 0.698 0.000 0.785 0.088 0.873 0.175 0.960 0.263 1.045 0.350 1.133 0.438 1.220 0.523 1.308 0.610 1.395 0.698
++ 3D dataset written to disk
4

That -infile_pattern parameter looks suspicious to me,
“7_MB*/*”. Specifically, Dimon is meant to process one
run at a time, and runs are typically stored in single
directories. So the wildcard before the ‘/’ does not
look good.

I suspect with multiple directories there, some have
the unsigned short issue, and some do not.

Would you verify whether multiple directories is
appropriate there? I expect not.

Thanks,

  • rick
5

The wildcard is there simply because the folder name contains subject information. The relevant directory (which is the only directory that starts with 7_MB) contains only the data for that one run, with no sub-directories.

The number of volumes is also correct, with 188 TRs in the run, and the run is indeed the seventh run (and the fifth functional run) for that subject.

6

Thanks for the details. It it not quite clear at a
glance where this may be going wrong. I will send
you a private message…

Thanks,

  • rick
7

So it seems I was a bit dense about this in the first
place. If particular runs are being converted, then
once in a while some number exceeds 2^15 - 1 in
the short data (i.e. evaluation as unsigned short is
required).

But then you have the mix of types to deal with, since
Dimon was only applying -ushort2float when needed.

I have just checked in a -ushort2float option to Dimon,
so you can have it always applied if you want it.

However, now you have a choice:
a. When detected (you have to look), make all data float
for the given subject.

b. In general, make all data float for all subjects.
This is more consistent, but uses much more disk space.

c. Perform some additional computation to force data to
be less than 2^15. This requires care for appropriateness.
Dividing by 2 is a possibility. You lose the big of resolution,
but it should be a stable operation, e.g.

3dcalc -a dset_float+orig -expr a/2 -datum short -nscale -prefix dset_short

Anyway, the -ushort2float option for Dimon will be available
after the next build, which will hopefully be tonight.

  • rick