Hi, Ellen-

A few comments:

A) For FreeSurfer (FS), you presumably ran recon-all and used some option or something to get another parcellation; if AFNI-land, we typically run @SUMA_Make_Spec_FS after running recon-all to bring all the default output into standard mesh GIFTI files and general-purpose NIFTI files; since your extra parcellation appears to be just a *.annot file, you could run @SUMA_Make_Spec_FS as usual, but add this option (see the help file for more options):

-extra_annot_labels L1 L2 ...  : convert extra annot files into ROI dsets
          e.g. -extra_annot_labels aparc
...

For example, if your usual command to translate FS output was:

@SUMA_Make_Spec_FS                            \
    -NIFTI                                    \
    -fspath FS_OUT_DIR                \
    -sid    subj_001

... then this could maybe be adapted to:

@SUMA_Make_Spec_FS                            \
    -NIFTI                                    \
    -fspath FS_OUT_DIR                \
    -extra_annot_labels     500_sym.aparc     \
    -sid    subj_001

Then, to map all the FS+@SUMA_Make_Spec_FS output to diffusion space, you can follow the FATCAT_DEMO2 example, via something like this:

fat_proc_map_to_dti                                                \
    -source          $path_P_ss/anat_02/SUMA/brain.nii             \
    -followers_NN    $path_P_ss/anat_02/SUMA/aparc*_REN_*.nii.gz   \
    -followers_surf  $path_P_ss/anat_02/SUMA/std.141.*.gii         \
    -followers_ndset $path_P_ss/anat_02/SUMA/std.141.*.niml.dset   \
    -followers_spec  $path_P_ss/anat_02/SUMA/std.141.*.spec        \
    -base            $path_P_ss/dwi_05/dwi_dwi.nii.gz'[0]'         \
    -prefix          $path_P_ss/dwi_05/indt

(found here: [afni.nimh.nih.gov])
... where you might just have another "-followers_NN ..." entry, for your new parcellation. Then your outputs would end up in the DWI space definitely.

B) Is your diffusion data oblique? If so, I would be a little concerned about the gradient values-- presumably the gradients are in "scanner coords", which is why you ran "3dWarp -deoblique .." on the diffusion data? That should (I think) keep the volumetric data and gradients consistent, assuming the gradients were written in scanner coords (not in the frame where the obliquity is ignored). I don't know about how gradients are recorded when the DWI FOV is oblique-- it would be good to check on that. The downside of running "3dWarp -deoblique .." on a volume is that it will slightly smooth it, because the dataset has to be regridded, applying the obliquity information. It may be there is no way to avoid that eventually, but first it would be good to check on the gradient coordinates (are they scanner coords or not).

C) What is this command doing?

3dAllineate \
-base dwi_ec_deob.nii.gz[0] \
-input dwi_ec_deob.nii.gz \
-prefix dwi_ec_allin.nii.gz \
-cost mutualinfo \
-verb \
-EPI

... is that meant to be distortion correction of some kind? Distortion correction should not be done that way. If it for another purpose, please describe it.

D) For 3dDWUncert, probably a larger number of iterations than 50 should be used, to get a better distribution for estimating uncertainty; I might use 300, even though it is a bit slow at times to calculate. This program *is* written to make use of multiple CPUs on a computer if you have OpenMP available, so it is worth setting OMP_NUM_THREADS in your script (e.g., in tcsh: "setenv OMP_NUM_THREADS = 6", assuming you have >6 CPUs on your current machine (you could use *all* threads on your machine, but probably don't want to).

--pt