Can't get Z slice distance right with DIMON

AFNI Message Board
, ,
1

AFNI version info (afni -ver):

Precompiled binary macos_13_ARM: May 19 2026 (Version AFNI_26.1.02 'Balbinus')

I am converting monkey CT and MRI scans from DICOMs to AFNI

I have always used Dimon for that, and it worked great for me, and still works great for T1 MRI, T2 MRI, and CT. Orientation is wrong but I fix it with 3drefit.

I now started converting TOF scans (acquired in the same session as T1 and T2), and my standard Dimon call does not get the slice distance right. Instead of 0.4 mm, I get 12.8 mm.

Here is how I call Dimon:

set noglob

dimon -infile_pattern *.dcm                         \

   -dicom_org                                    \

   -gert_create_dataset                          \

   -gert_to3d_prefix ${subjname}_${scan_type}     

unset noglob

And the output is: (note that Dimon reports z_delta 0.4 which I think is correct, but to3d reports Voxel dimensions: 0.1953 X 0.1953 X 12.8000 mm

Dimon version 4.36 (March 28, 2025) running, use <ctrl-c> to quit...



-- scanning for first volume

.

-- first volume found (136 slices)

-- scanning for additional volumes...

-- run 4: 1 



final run statistics:

    volume info     :

        slices      : 136

        z_first     : -20.05

        z_last      : 33.95

        z_delta     : 0.4

        oblique     : no

        mos_nslices : 0 



    run #   4 : volumes =   1, first file (#0) = Leclerc_4_1_DumO11.dcm



++ writing dimon file list to dimon.files.run.004

set OutlierCheck = 

to3d -prefix LECL_TOF -@

++ to3d: AFNI version=AFNI_26.1.02 (May 19 2026) [64-bit]

++ Authored by: RW Cox

++ It is best to use to3d via the Dimon program.

++ Counting images:  total=136 2D slices

*+ WARNING: If images are wrong, try using '-assume_dicom_mosaic'?

++ Each 2D slice is 464 X 512 pixels

++ Voxel dimensions: 0.1953 X 0.1953 X 12.8000 mm

++ Image data type = short

++ Reading images: ..................................

++ 3D dataset written to disk

I tried the -use_slice_loc option, but it did not fix the issue (and it messed up Dimon-ing the CT, which uses the same script).

Currently I am brute-force fixing it with an additional 3drefit:

if ($scan_type == TOF ) then

   3drefit -zdel 0.4 \

   ${subjname}_${scan_type}+orig

endif



3drefit -orient $orient_string ${subjname}_${scan_type}+orig

but I was wondering if there is a way of fixing it at the source?

Also, reading 3drefit help:

-xdel dimx Makes the size of the voxel the given dimension,
-ydel dimy for the given axis (x,y,z); dimensions in mm.
-zdel dimz ** WARNING: if you change a voxel dimension, you will
probably have to change the origin as well.
-keepcen When changing a voxel dimension with -xdel (etc.),
also change the corresponding origin to keep the
center of the dataset at the same coordinate location.

I thought I should use -keepcen, but I found out that -keepcen puts the origin in a wrong location. When the crosshair was in the brain, z was around -750 mm, and when I did not use keepcen everything was fine. Am I misunderstanding something, or is -keepcen doing the opposite of the documentation?

2

Hi Pawel,

It seems unlikely that you would want -keepcen. The could keep the center of the volume in the same location, but it is most likely far off, given that the slice size is.

What is the to3d command that Dimon ends up running (from the GERT_Reco script)? It would be nice to see why Dimon and to3d are coming up with difference slice sizes.

Feel free to modify filenames for any PII.

Thanks,

-rick

3

Hi Rick,

GERT_Reco is minimal

set OutlierCheck = ''         # use '-skip_outliers' to skip



to3d -prefix LECL_TOF  \

-@ < dimon.files.run.004

and identical to the conversions that are successful, here is one for CT for comparison

set OutlierCheck = ''         # use '-skip_outliers' to skip





to3d -prefix LECL_CT  \

-@ < dimon.files.run.001

NHPs so PII not an issue, I think.

4

It is surprising that to3d and Dimon are coming up with different values. Would you please copy the to3d script to a new file, and try (individually perhaps) adding '-oblique_origin' and '-use_last_elem' and see if those help?

If there is any chance that I could get a couple of volumes of DICOM files, that might be helpful.

Thanks,

-rick

5

I ran a copy of the GERT script with either of these two options as well as with both of these options and each time I got 12.8 mm.

I'll share those TOF DICOMs with you via OneDrive

6

I have the files and see the same issue. It is strange. But I will do some hunting.

Thanks!

-rick

7

So where the 12.8 is coming from is clear, but it took longer to track down (and then recall) that Dimon actually computes dz based on coordinates for consecutive slices, whereas to3d simply takes the dz value from the DICOM files.

In this case the DICOM files seem to have an incorrect value of 12.8 in element 0018,0088, ACQ Spacing Between Slices.

Is this a new sequence?

-rick

8

I do not think it is new, but I never imported TOF into AFNI before, I only inspected them visually.

I can let Bldg 49 NIF know, this was done by them on their scanner.

9

That sounds good.

I see that dcm2niix handles that better, though I do not know how it decides on 0.4 instead of 12.8.

Thanks,

-rick

10

In DICOM, (0018,0088) Spacing Between Slices is the center-to-center distance between adjacent slices, whereas (0018,0050) Slice Thickness is the nominal slice thickness. These two values do not have to be equal. For overlapping slices or slabs, Spacing Between Slices can be smaller than Slice Thickness; for gapped acquisitions, it can be larger.

11

Hello,

Yes, which suggests that 0018,0088 should be used to determine the slice deltas and volume size in any case, based on the center-to-center distances, while the nominal slice thickness would not imply the difference in slice coordinates.

-rick

12

AFNI does not support 3D datasets with gaps between slices or with overlapping slices/slabs. The best it could do for gaps between slices would be to put synthetic all-zero slices between the real slices -- assuming the inter-slice gap is an integer multiple of the slice thickness.

I cannot see off the top of my head how AFNI could support overlapping slices. The relationship between xyz coordinates and ijk indexes is a simple affine one, and the volume data is supposed to be a regular grid sampling of a univalent function over a 3D box.

13

I expect that AFNI does not really need to care how thick the slices are, it just needs to track the values at voxel centers. For thick, thin or standard(?) slice sizes, relative to delta-z, there should still be a single value per coordinate, and those coordinates should still be on a regular grid.

If someone wanted to track overlapping slices in some new way, for example to alter how interpolation is done when warping, that would require a substantial change/new method for the process, as well as adding such information to the dataset. But I suspect that isn't the expectation in this case.

-rick

14

Yes, that's what I need: put a CT (bone), a T1 (brain), a T2 (brain), and a TOF (major vessels) all from the same subject in the same space so I can play with all of them at the same time. Ultimately, for the purpose of designing a chamber that will fit to the bone (CT) and provide access to specific brain regions (T1, T2) with a cannula that would also not hit major vessels (TOF).

15

Hi Pawel,

To be sure, so what you need is just data at voxel centers on a regular grid, is that right? That would mean either altering the DICOM files to have 0.4 instead of 12.8, giving to3d an option to override that (0018,0088) value, or both.

What does the 12.8 slice delta mean in this case? What is the number intending to imply with your data, given that the actual delta is supposed to be 0.4? Or given Bob's comment, perhaps that is more of a volumetric delta, maybe even between multi-band origins?

Thanks,

-rick

16

Yes, voxel centers on a regular grid all I need. Overriding the (0018,0088) value is what I am currently doing with 3drefit -zdel 0.4

I have frankly no idea what 12.8 means. In conversation with NIF people this was (tentatively) proposed "The AFNI issue is probably specific to time-of-flight angiography because I believe it uses multi slab, where the slices within each slab overlap. The number provided in the DICOM header element ('12.8') seems to correspond to 32 x 0.4mm slices, which I think might be the slab spacing rather than slice spacing", and then @cecilyen provided the information above.

I am a simple person :wink:, I have no idea how TOF magic happens, I just want the bright voxels that indicate vessels to be in the same space/coordinate system as my other scans.

I did not know there is anything unusual with TOF DICOM slices until I tried importing into AFNI. All three DICOM viewers I use interpret these DICOMs as 0.4-mm spaced. So does 3D Slicer, e.g.

image
image554×106 2.64 KB

17

Various AFNI programs use the get_dz()function in mri_read_dicom.c, where there are various possibilities for the slice thickness to be computed from the SLICE_SPACING and SLICE_GAPDICOM elements -- as in my experience, strange things have happened (including GE files that used DICOM incorrectly). If changes need to be made to make to3d work properly, this might be a place to start.

18

That sounds good, thanks. It is not clear how to best implement this, since IS_GAP is only Y/N. I *could* add a "THICK" case for that variable, violating the Y/N aspect. Or add a new env var. Sticking with just the one env var seems preferable.

Then Dimon needs to recognize this case, which it probably can, or use an option.

Does allowing AFNI_SLICE_SPACING_IS_GAP to be YES/NO/THICK seem too offensive?

Thanks,

-rick

19

Sorry, from the point of view of a user - does it have to be doe an env var? Is there a reason no to control this behavior via a parameter to to3d (and possibly a parameter to dimon that would be passed to to3d)? I personally find controlling things via env variables less handy and more prone to mistakes.

20

While I would normally agree with that, in this case, either way should be straightforward. If we abuse the env var, Dimon should be able to recognize this case and handle application of the env var (in the GERT_Reco script) on its own. Then you wouldn't have to do a thing (except use the updated Dimon/to3d).

Of course, having you control it via an option would be quite feasible as well. But even with an env var, one could run something like:


to3d -DAFNI_SLICE_SPACING_IS_GAP=USE_THICK ...

Or maybe I should just add an option to Dimon (and not to3d), and again have Dimon handle the env var for to3d in GERT_Reco. Would that be reasonable?

-rick