Thanks Paul! Such good info!!

Your questions:

Quote
pt
To be clear, is "@Make_Special_FS" actually "@SUMA_Make_Spec_FS"? I am also confused by what "your" T1 is here.

Yes, I should have corrected that, it is @SUMA_Make_spec_FS.
The two T1-images I am referring to is
T1: our original T1-weighted MRI scan, I'll call it T1-orig from now on.
The other T1 is the ../SUMA/T1.nii.gz file: It is a file generated in the ../SUMA/ dir. It always has the same dimensions as the ROIs (e.g. wm_seg.nii.gz) and has always matched perfectly with the ROIs in the viewer. I guess it is corresponding to the freesurfer_sub/mri/T1.mgz file which you can use as an underlay when reviewing the segmentation in free-view.

1) Normal recon-all case
Yes! Yet another occasion where you saved us by helping with obliquity.
When preforming all this on the T1-orig (from both scanning sessions, so T1_orig_TP1 and T1_orig_TP2) before feeding it into FS:

#T1_orig (scan1) example
#De-oblique the data
3dcopy sub109-1_sT1W_3D.nii tmp
3drefit -oblique_recenter tmp+orig
3drefit -deoblique tmp+orig 
3dcopy tmp+orig sub109-1_sT1W_3D_do.nii
#get rid of space below brain
3dZeropad -I -70 -prefix sub109-1_sT1W_3D_do_zp.nii sub109-1_sT1W_3D_do.nii
#set center of mass inside the brain
3dCM -set 0 0 0 sub109-1_sT1W_3D_do_zp.nii

The single run of recon-all gave excellent overlap between T1_orig_TP1 and the wm_seg.nii.gz outpuf file.

Question: Since we did the commands

3drefit -oblique_recenter tmp+orig
3drefit -deoblique tmp+orig

Should we still keep the "-deoblique_refitly" option in:

@SSwarper -input ${T1_data} -base /usr/local/abin/MNI152_2009_template_SSW.nii.gz -deoblique_refitly -subid ${sub_id} -giant_move -odir $startdir/pre_warp_${sub_id}

The command above has been working fine on the raw T1_orig before, but before we have not deoblique:ed them prior to @SSWarper. The documentation of 3drefit suggests that we should keep deoblique_refitly.

2) Longitudinal case of recon-all
Sorry, I am no expert on the inner workings of this pipeline and I don't expect you to be either.
This is a link the documentation.
And a section:

Quote

The longitudinal scheme is designed to be unbiased with respect to any time point (TP). Instead of initializing it with information from a specific time point, a template volume is created and run through FreeSurfer. This template can be seen as an initial guess for the segmentation and surface reconstruction.

I would think, and it would make sense, that the output of the longitudinal run should still be in "orig" space. But we still get this shift. See image at the end.

After it has made the template, in template space, we launch the final recon-all, for each time point individually, using the -long flag. Example for T1_orig_TP1:

recon-all -long TP1 ${subject}_Template -all -sd $subject_dir & PIDT1=$!

I.e., it goes into the subject dir, locates the "TP1"-dir (results of the normal recon-all process using only T1_orig_TP1 where the TP_orig totall matches wtht the SUMA/wm.nii.gz file) and and the path/name of the template_dir which is where FS made the template (based on TP1_orig and TP2_orig).
The question is if the end results ends up in TP1/TP2 space respectability or in "template space". It should be orig-space...

In summary, it is hard for me to know if I should look into more ways of "fixing" my data since the output SHOULD be overlapping with the T1_orig or if should not, since it is in template space. I'll try to contact the author of the pipeline and get back to this =). Worst case, we will settle with using recon-all on the TPs separately and skip the longitudinal pipeline.

Top: Overlap of T1_orig_TP2 and normal recon-all wm_seg.nii.gz output
Bottom: Overlap of T1_orig_TP2 and the longitudinal output of wm_seg.nii.gz



Edited 1 time(s). Last edit at 09/01/2021 02:17PM by Robin.