Howdy-

Re. #1: I guess that means that you used non-AFNI programs to generate the MASK.nii.gz file; AFNI ones tend to store a growing list of the commands used into the header, so you can check back for reference later. Okeydoke.

Re. #2a: After running FreeSurfer (FS), you can run @SUMA_Make_Spec_FS to convert the *.mgz/etc. formatted files into NIFTI and GIFTI that other software use. Here is a brief blurb about integrating FS and AFNI like this:
[afni.nimh.nih.gov]
... where you will also get some useful groupings of parcellation and segmentation files (like, maps of WM, GM, ventricle, CSF and other classes), standardized surfaces meshes (so you can use them for group analysis directly), etc.

Re. #2b: There is a (large) tutorial on processing diffusion data with AFNI, including TORTOISE for distortion correction and FS for parcellation segmentation. It is the FATCAT_DEMO2, which is downloadable with the eponymous AFNI command:
@Install_FATCAT_DEMO2
... where there is a full script (do_01_subj_complete.tcsh) and most of the demo output (some intermediates removed, for file size sake), and here is the online set of pages about it:
[afni.nimh.nih.gov]
The online pages have full descriptions of outputs and pictures of things, to help understand the steps.
The specific part about mapping GM ROIs to DWI space from FS output is here:
[afni.nimh.nih.gov]
... basically using the command fat_proc_map_to_dti (probably you would want to use @SUMA_Make_Spec_FS prior to this, so the relevant outputs are there).
... and the part about inflating the mapped ROIs potentially and preparing for tracking is on the subsequent page:
[afni.nimh.nih.gov]
... although I note this is even easier now, because @SUMA_Make_Spec_FS now makes a volume of the subset of FS GM ROIs that are just the ROI-like ones (FS estimates a kind of "generic" GM in a few places dotted around the GM, typically borderline cases, and so those shouldn't be included in tracking; the 3dcalc command there isn't necessary; you can use the "*REN*gmrois*" files).

Re. #3: The alignment does look pretty good, though it can be a bit hard to judge with the ROIs being opaque... I think trying fat_proc_map_to_dti might still be useful. The FATCAT_DEMO2 also includes an example of inflating ROIs in a controlled manner, which might be useful, as well (note how gaps can appear between the ROIs from mapping-- the same thing can happen at the GM-WM boundary, making tracking more difficult).

Re. #4: Great, thanks. So, *those* 4 datasets have no obliquity (just keeps things simple), and are apparently on the same grid (that is what the 1 means). Sooo, that's good, but now the question is why 3dTrackID showed that some of the inputs *were* oblique and *did* have different numbers of voxels...?

Are you sure that your initial 3dTrackID command was using *those* files, and that "find" command isn't leading to other ones (with similar names) being input? Can you run the above 3dTrackID command with an additional option "-echo_edu", which should spit out the full 3dTrackID command being used, with any paths to files expanded and clearly defined? We want to make sure we are examining the same files...

Also, this should use the same files that were being input into your 3dTrackID command:

find SPN01* -type f | nohup parallel 'dtipath="/home/eji/projects/spins/preproc/fsl/subjects/w0" && cd {} && cd afni && \
3dinfo \
-obliquity \
-same_grid \
-orient \
-n4 \
-ad3 \
-prefix \
DWUncert+orig. \
$dtipath/{}/mri/parc5002dwi.nii.gz \
$dtipath/{}/MASK.nii.gz \
3dDWItoDT_DT*' ::: * &

5) Note also that having 318 ROIs in your GM map is a lot, and can lead to pretty big memory usage potentially; when you ran your successful test case, is this the input GM "netrois" file that you were using?

--pt