Use to3d to convert dcm to nii from different dicom header

Hello All,

Apologies if i am asking some weird nonlogical question.

I have a qsm data in .dcm format after running medi-tool box pipeline on it. I am looking forward to converting it into a nifty format using to3d/dimon. However when i do so i get many errors apparently because of improper header information after running medi pipeline on .dcm images.

Following are the messages spitted out after running dimon,

– scanning for first volume
++ DICOM WARNING: Slice_Spacing=1.000000 smaller than Slice_Thickness=2.000000

++ Setting environment variable AFNI_SLICE_SPACING_IS_GAP ++
++ to YES will make the center-to-center slice distance ++
++ be set to Slice_Spacing+Slice_Thickness= 3.000. ++
++ This is against the DICOM standard [attribute (0018,0088) ++
++ is defined as the center-to-center spacing between slices, ++
++ NOT as the edge-to-edge gap between slices], but it seems ++
++ to be necessary for some GE scanners. ++
++ ++
++ This correction has been made on this data: dz= 3.000. ++
++ ++
++ Setting AFNI_SLICE_SPACING_IS_GAP to NO means that the ++
++ DICOM Slice_Spacing variable will be used for dz, replacing ++
++ the Slice_Thickness variable. This usage may be required ++
++ for some pulse sequences on Phillips scanners. ++

++ DICOM WARNING: Slice_Spacing=1.000000 smaller than Slice_Thickness=2.000000
++ DICOM WARNING: no more Slice_Spacing messages will be printed
*+ WARNING: Bad DICOM header - assuming oblique scaling direction!

– first volume found (1 slices)
– scanning for additional volumes…
– run 99: 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
** volume match failure (bad zoff -87.480904 != -88.480904)
(estimated index 1.000000, want index 0)
(for more details, replace -no_wait with -quit)

final run statistics:
volume info :
slices : 1
z_first : -88.48
z_last : -88.48
z_delta : 1
oblique : no
mos_nslices : 0

run #  99 : volumes =  33, first file (#0) = /Users/spkadam/Desktop/DICOM/SORTED/99/1.dcm

Inorder to tackle this, i am planning to use header info of non processed(i.e dcm file before running qsm/medi pipeline) dicom images. However with the errors as above i am not sure how to go ahead with this.
Can anyone suggest if its possible for to3d command to use header info from one dicom file to convert another set of dicom images to nii?

Any thoughts?


These messages are warnings not errors, so maybe you don’t need to be so worried. Just check that the output data is what you think it should be. In this case, the warnings are about the thickness of slices. Are the slices 1mm or 2mm? If it’s not right, use the instructions included in the message. DICOM files can be confusing, and they vary from manufacturer to manufacturer and even within a scanner manufacturer’s DICOM data. You will have to be careful, but this kind of thing should be easy to see visually or from the header of the dataset with 3dinfo.

Hi KashiV,

In addition to Daniel’s comments, there does seem to be a
problem after the 33rd volume. And were you able to answer
the question of what dz is used (1.0, 2.0 or 3.0)?

But to figure out what is going wrong with volume 34, it
may be necessary to add or use different options, though
your options were not shown.

Consider adding “-save_details DET” and mailing me the
DET* files (click on my name for the email). That might
shed light on the error.

  • rick

Hi KashiV,

Is this 33 sets of 4-slice volumes, plus another 20
images at once slice?

It actually looks like there should be many more
slices, as if it is only part of an archive. But the
files are ordered by time and then by slice (so
slice-major and time-minor, say, which is not

  • rick