Howdy-

OK, indeed, FreeSurfer (FS) output will be a 256x256x256 matrix with 1x1x1 mm**3 voxels, regardless of input (you can actually specify using a higher res output if you have higher res input, but that doesn't apply here). Your input to FS might *not* be the same matrix size or have the same voxel dimensions, indeed. Your input to FS might also have an obliquity matrix, which I don't think the FS output will have---that obliquity matrix is an extra spatial transform (in practice, likely describing mostly a rotation+translation, though it could be more general), based on how you acquire your data.

Nomenclaturally, I would say that if there is no extra obliquity matrix in the input, then the FS output and the FS input are in the same *space* (they should overlay) but on different *grids* (voxel size and/or matrices differ).

To check about the obliquity of the input and outputs, what is the output of:

3dinfo -obliquity -prefix DSET

... for both your FS input and the *SurfVol*.nii?

You can also use 3dinfo to see if 2 or more dsets have the same grid (with the latter option sharing a bit more details about grid properties---please see the help description):

3dinfo -same_grid DSET1 DSET2 ...
3dinfo -same_all_grid DSET1 DSET2 ...

To have the same transformation between the two anatomical volumes also apply to the atlas (or atlases) of interest, you can input your atlas created by FS as a "follower", such as here (use the "-atlas_followers" option, too, if the followers are all atlases, so that nearest neighbor interpolation is applied:

@SUMA_AlignToExperiment \
     -echo -exp_anat tmp_anat+orig. \
     -surf_anat FT_SurfVol.nii    \
      -atlas_followers \
       -prefix ATE \
       -atlas_followers \
      -surf_anat_followers aparc.a2009s+aseg_REN_all.nii.gz aparc.a2009s+aseg_REN_gmrois.nii.gz

It should then get translated and resampled (and interpolated) appropriately to your native/input anatomical space. The above gave me the following outputs:

ATE+orig.{BRIK,HEAD}
aparc.a2009s+aseg_REN_all.nii_Alnd_Exp+orig.{BRIK,HEAD}
aparc.a2009s+aseg_REN_gmrois.nii_Alnd_Exp+orig.{BRIK,HEAD}

...that all appeared to be on the input dset grid. Now, my input dset did *not* have obliquity, so I am not sure if it will match that---could you try and see if yours does (if you input dset did have obliquity, as seen above)? You can check the obliquity of these dsets, too with:

3dinfo -obliquity -prefix *Alnd_Exp*HEAD

Further, if you wanted to reattach the labeltables from the FS-created atlases to the @SUMA_AlignToExperiment ones, you could do this:

3drefit -copytables aparc.a2009s+aseg_REN_all.nii.gz aparc.a2009s+aseg_REN_all.nii_Alnd_Exp+orig.HEAD
3drefit -copytables aparc.a2009s+aseg_REN_gmrois.nii.gz aparc.a2009s+aseg_REN_gmrois.nii_Alnd_Exp+orig.HEAD

How does that all work?

--pt