confirm 3dmaskdump radius spec is in "mm"

Could someone confirm that the “-xball x y z r” option for 3dmaskdump specifies radius in mm?


Hi, Andrew-

Yep, the code looks good to me.

As an example, using data in the Bootcamp’s AFNI_data6/afni/ directory:

# make a very anisotropic dataset
3dresample -dxyz 1 2 4 -input anat+orig. -prefix anat_124.nii.gz

# now, use that option to ask for a rad=21 mm ball around the origin, dumping all the voxel values to a text file
3dmaskdump -xball 0 0 0 23 anat_124.nii.gz > coords_ball.1D

# turn that text file into a dset of its own
3dUndump -prefix UNDUMP.nii.gz -master anat_124.nii.gz -ijk coords_ball.1D 

… and the attached is the image created by overlaying UNDUMP.nii.gz on anat_124.nii.gz. The re-created dset is indeed isotropic, and by clicking around in the GUI, we can see that the edge voxels in the overlay appear to have their centroid just within that radius.


Well, actually, my smarter colleagues here have determined that there actually is a problem with the way 3dmaskdump works if the voxels are sub-mm (there is an int-to-float conversion problem internally). So, running my previous example above with a 0.25 x 0.5 1 mm3 voxel dset (as opposed to 1x2x4 mm3 dset in my example above) will not produce a sphere.

Fixing this is underway… Thanks for the question!


Note that the update for sub-mm voxels has been compiled and distributed. You can get the update with:

@update.afni.binaries -d

Thanks for the question!

  • rick

thank you all! This would then apply to 2.5mm3 voxels, too?


There should not be any difference for xball in a dataset with 2.5mm voxels with this change.
It might be good to add some details.

  • rick