ROI miss-match with orig T1 when using recon-all (and longitudinal) output in SSwarper?

Hi! This is regarding FreeSurfer + @SSwarper:

We have been pulling our hair out over wierd stuff happening. Following the guide, we simply run recon-all -all where we input our orig T1:
T1=/path/T1.nii
This generates the /path/freesurfer/subX dir where we run @Make_Special_FS command which generates the dir
/path/freesurfer/subX/SUMA where we find all masks/ROIs. Also, we find a T1.nii.gz image.

Normally we procede to our afni_proc.py script, where we run @SSWarper. According to the guide we feed it with the orig T1:


@SSwarper -input FT_anat+orig

So we set:
T1=/path/T1.nii

The normal case of ordinary recon-all:
What happens is that FS resamples the input a little bit, for example it always makes the matrix “cubically-isotropic”. If the input (T1) is:
170x256x256, then the output space of e.g. wm_seg.nii is 256x256x256. This is also the dimentions of the …/SUMA/T1.nii.gz file.
The …/SUMA/T1.nii.gz file is always a perfect match with the ROIs/maks/segments.

If I would copy your orig T1 into the SUMA dir and look at how the ROIs align, it is usually fine. Even though the orig T1 does not have the same matrix dims (why is that?).
The alignment of orig T1 and the ROIs can, however, be shifted (as we noticed) from a few voxels to a lot when using the orig T1 as underlay and wm_seg.nii as overlay. This off shift does, ofc, follow into the proc.results dir when overlapping anat_final with follower_wm.nii.gz (also true when looking at copy_wm._seg.nii.gz over T1 in orig space, so not a “warping issue”) This often completely disappears if you have processed your orig T1 a little bit before feeding it into recon-all by setting the center of the image to (0,0,0) and cut out some of the neck (yes, we have been up late testing things).
For example, one subject had horrible T1 orig and wm_seg.nii aligment when just feeding it raw into FS.
But when we ran: (this is from an old discussion with Paul Taylor on old issues we had with SSWarper =)).
#get rid of space below brain
3dZeropad -I -70 -prefix sub${sub}-1_T1_zp.nii sub${sub}-1_sT1W_3D.nii
#set center of mass inside the brain
3dCM -set 0 0 0 sub${sub}-1_T1_zp.nii
And then fed FS with the zero-padded and center of mass:ed T1 the alignment was almost perfect.

What ALWAYS works though, is to just feed SSWarper with the …/freesurfer/SUMA/T1.nii.gz file instead. This simply seems to be the orig T1 but in the same space as the ROIs and the same matrix dims.

Note: I might be fooled by some de-obliqe magic here. Maybe the orig T1 is perfectly aligned with the masks/ROIs but the viewer tells me otherwise. However, the matrix dims do miss-match.

Would you recommend to use …/freesurfer/SUMA/T1.nii.gz as input to SSwarper instead of:
@SSwarper -input FT_anat+orig
Like in the documentation.
Also, this helped us:
3dZeropad -I -70 and 3dCM -set 0 0 0 on T1 prior to recon-all

I might be off here, but visually we noticed that 3dZeroPad + 3dCM on the data prior to feeding it into FS did the trick. But even with orig data without 3dCM, …/SUMA/T1.nii.gz gave really good results.

The freesurfer -longitudinal way
The guide probably assumes a normal freesurfer recon-all have been run. But sometimes, like in our dateset, you have two scans separated with a month or two. Then you can improve the quality by using the longitudinal pipeline:
Run T1.nii.gz from session 1 and T1.nii.gz from session 2 in two separate normal recon-all runs, call the output dirs TP1 and TP2.
Then run recon-all with the -base option to generate a template based on TP1 and TP2:


recon-all -base ${subject}_Template -tp TP1 -tp TP2 -all -sd $subject_dir -parallel

This gives a sub_id_Template dir
Then you run two separate longitudinal recon-all runs on the original data:


#TP1
recon-all -long TP1 ${subject}_Template -all -sd $subject_dir
#TP2
recon-all -long TP2 ${subject}_Template -all -sd $subject_dir

This gives new outout dirs:
TP1_subid.long
TP2_subid.long
I.e. segmentation but it has used the knowledge of two scans, separated in time, to get better results.
We can then run @Make_Special_FS in each of these .long-dirs to get the SUMA dir with the ROIs/masks for TP1 and TP2. We are just interested in the second scan (TP2) but use TP1 to improve segmentation.

As I understand it, these ROIs are in “template space”. It is quite a big miss-aliment of the …/TP2.long/SUMA/wm_seg.nii.gz and the orig TP2 orig input image. I compared the shift to the normal single run (with bad aligment due to not using 3dCM) and the shift is different. The respective TPX.long/SUMA/T1.nii.gz file matches perfectly, again, with the ROIs. TP1.long/SUMA/T1.nii.gz and TP2.long/SUMA/T1.nii.gz are pretty much perfectly aligned which indicates that we are in a “common space” between the two orig T1 images. I.e. Template space.

The only way for us to make the ROIs match was to feed SSwarper with the TP2.long/SUMA/T1.nii.gz file instead of the orig time point 2 T1 image (TP2 since we only want the data from the second fMRI session).

Our question, does our fix sound legit in the longitudinal case? I.e., point to the T1.nii.gz file in the SUMA dir of the corresponding longitudinal time point instead of the orig data:


#we replaced
@SSwarper -input FT_anat+orig 
#with
@SSwarper -input $SUMA_dir/T1.nii.gz

I am aware that I can be completely wrong, but this is the only conclusion we came up with after working on this for a couple of days.

This was done in collaboration with another AFNI-user, Irene Perini =)

Please let me know if we made a huge mistake somewhere or if we could be onto something.
Thanks!

Hi, Robin–

There is a lot going on here… I for one have never run the FS recon-all longitudinal pipeline, so I am not sure what is happening there.

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

There are a lot of things that can be happening here. As your data changes (coordinates become less well-centered, obliquity is used or not the FOV size changes), some of these considerations can become more or less important.

  • If it were me, to start I would deoblique my T1w dataset; doing it as follows will preserve where the coordinate origin (x,y,z)=(0,0,0) is:

3dcopy DSET_INPUT tmp
3drefit -oblique_recenter tmp+orig
3drefit -deoblique tmp+orig 
3dcopy tmp+orig NEW_DSET.nii.gz

  • If there is a huge amount of non-brain material, this might negatively affect alignment, esp. in finding the initial starting point (and it makes the files bigger and more unwieldy, needlessly, too). For that, as you have shown, 3dZeropad can be useful.
  • If your coordinate origin is not in a reasonable spot, then using 3dCM can be very useful, too.

At this point your anatomical shoudl be in good shape for everything. If there is a mismatch between the initial anatomical and the FreeSurfer, regular recon-all output and the contents of the SUMA/ directory, I would assume that that is due to having obliquity in the original is not being propagated along. This can be verified with:


3dinfo -obliquity -prefix DSET_INITIAL DSET_IN_SUMA_DIR

Even though your acquired anatomical might have voxels that are not 1mm isotropic and matrix dimensions that are not 256x256x256, the initial dataset and SUMA/ directory contents should overlay if the initial did not have obliquity. This is because AFNI uses the coordinates to locate data in space, not just voxels stacked from a corner so voxel size and matrix dimensionality would matter.

Re. the longitudinal analysis, I don’t know what the “template space” you refer to is. Is it something that overlaps neither T1w_1 nor T1w_2 (the anatomicals at each time point)? If that is the case, then I don’t see why the volumetric ROIs should overlap eiither input dataset (by definition). Or is this just about obliquity again? The initial T1w_? dataset is oblique, but the output of recon-all and @SUMA_Make_Spec_FS is not?

–pt

Thanks Paul! Such good info!!

Your questions:

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.

  1. 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:

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

Hi, Robin-

I’m glad that was useful, and thanks for clarifying some of the original message.

Just as a nomenclature point, the “T1” in the SUMA/ directory is the one with “SurfVol” in the name, yes? We usually refer to that as the “SurfVol dataset” (for guessable etymology). It does have the same grid as the output ROIs (aparcnii, REN, wmseg, etc.). NB: I just processed a “T1w orig” that had obliquity, and none of the NIFTI datasets in the output SUMA/ directory come out with obliquity. So, if your input dataset is oblique, it will not directly overlay on these outputs—I think you could use @SUMA_AlignToExperiment to align the SUMA/ directory sets to the input. But if you deoblique your data before putting it into recon-all, then the data will overlay fine in the AFNI GUI (though, likely the grids will be different, because FreeSurfer makes the 1mm isotropic voxels in a 256x256x256 matrix datasets).

Re. “1) Normal recon-all case”
Yes, if you deoblique your original dataset, then “-deoblique_refitly” should not be doing anything, because there is no obliquity to apply.
One small thing I just noticed will happen by default with keeping “-deoblique_refitly” is that the deobliqued dataset will have RAI data orientation by default. It won’t move at all spatially (at least not in AFNI), but I had not noticed this before. I might add something to change that within @SSwarper.
But in general, removing obliquity while “keeping the coordinate origin”, with this does:


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

… seems to me to be preferable than applying the obliquity with “-deoblique_refitly”—if there is obliquity in the dataset, then it would be regridded (=blurred a bit) by applying the obliquity. Why have unnecessary blurring? And why not make it easier for outputs to match inputs? So, I would do the above deobliquing-while-keeping-coordinate-origin at the start, and not do include “-deoblique_refitly” in @SSwarper.

Re. the longitudinal aspect—I am afraid I don’t know. I don’t have a good set of data to test this. If I were approaching this, I would deoblique both input anatomicals (probably preserving the coordinate origin, as described before) to remove that possible hassle. At the end of it all, it strikes me the final data should overlay either the first “T1w orig”, the second “T1w orig”, or, if the program is generating some intermediate “template”, then that space. It is hard for me to see how the datasets could not overlay one of these three possibilities (assuming the issue is not due to obliquity in the input).

I would be curious if you could upload a pair of datasets and I could use your commands to see what happens; however, I will be out for a couple weeks shortly, and I am afraid I won’t have time to run everything before heading out.

–pt

Hi!

Just as a nomenclature point, the “T1” in the SUMA/ directory is the one with “SurfVol” in the name, yes? We usually refer to that as the “SurfVol dataset” (for guessable etymology)

Not really, but they are basically the same. In the generated SUMA-dir we have:
ls ~/FREE_SURF/sub109/TP1/SUMA/


etc...
sub109_SurfVol.nii
T1.nii.gz
etc...

But they give almost identical 3dinfo outputs, I think only the intensity is different.


3dinfo -obliquity -prefix T1.nii.gz sub109_SurfVol.nii 
0.000	         T1.nii.gz
0.000	sub109_SurfVol.nii

But if you deoblique your data before putting it into recon-all, then the data will overlay fine in the AFNI GUI (though, likely the grids will be different, because FreeSurfer makes the 1mm isotropic voxels in a 256x256x256 matrix datasets).

Yes, but this was no problem, right? With deobliqued data as input, we get good visual overlap between T1-orig and SUMA/wm_seg.nii.gz and it is no problem, later on in afni_proc, that they have different grids, right?

Yes, if you deoblique your original dataset, then “-deoblique_refitly” should not be doing anything, because there is no obliquity to apply.

Oh, okey! When reading the 3drefit documentation for the operations we do:


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

Then we understood it as “3drefit -deoblique” doesn’t actually deoblique the data?


-deoblique      Replace transformation matrix in header with cardinal matrix.
                  This option DOES NOT deoblique the volume. To do so
                  you should use 3dWarp -deoblique. This option is not 
                  to be used unless you really know what you're doing.

Also, the option -oblique_recenter warns about a potential shift due to rounding?


-oblique_recenter
                  Adjust the origin so that the cardinalized 0,0,0 is in
                  the same brain location as that of the original (oblique?)
                  (scanner?) coordinates.
                  Round this to the nearest voxel center.
                * Even if cardinal, rounding might cause an origin shift
                  (see -oblique_recenter_raw).

But if all that is fine, we will remove “deoblique_refitly” from SSwaper =).

recon-all long:

If I were approaching this, I would deoblique both input anatomicals (probably preserving the coordinate origin, as described before) to remove that possible hassle.

This is what we finally did.
We ran this on both T1-scans for this subject:


#T1-1 (scan1)
#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

Then we fed the “fixed” volumes to the recon-all long pipeline:


sub109-1_sT1W_3D_do_zp.nii
sub109-2_sT1W_3D_do_zp.nii

That is good about the pipeline is that you also get the normal recon-all process results in step1. That’s why I yesterday could say that the standard recon-all now gave good results but the final -long results did not. I’ll summarize:

  1. Using RAW (oblique) data in the NORMAL recon-all process only using TP1 (sub109-1_sT1W_3D.nii)
    Visually bad alignment, our initial issue

3dinfo -obliquity -prefix sub109-1_sT1W_3D.nii SUMA/wm.seg.nii.gz 
4.874	sub109-1_sT1W_3D.nii
0.000	       wm.seg.nii.gz

  1. Using deobliqu operations above on RAW (oblique) data, feed that to the NORMAL recon-all process only using TP1 (sub109-1_sT1W_do_zp_3D.nii)
    Visually really good alignment, and thats why I wrote that your suggestion fixed it!

3dinfo -obliquity -prefix sub109-1_sT1W_3D_do_zp.nii SUMA/wm.seg.nii.gz 
0.000	sub109-1_sT1W_3D_do_zp.nii
0.000	             wm.seg.nii.gz

  1. Now we move to the longitudinal pipeline, using sub109-1_sT1W_do_zp_3D.nii and sub109-2_sT1W_do_zp_3D.nii, i .e. the deobliqued raw data.
    Step1.long) Generates normal recon-all for both time points. The results are identical to case 2) above.
    This is the final output dir:

robka@maul:~/FREE_SURF/sub109$ tree -L 1
.
├── fsaverage -> /usr/local/freesurfer/subjects/fsaverage
├── sub109_Template (template made from TP1 and TP2 below)
├── TP1 (normal recon-all output for TP1)
├── TP1.long.sub109_Template (final longitudinal output TP1)
├── TP2 (normal recon-all output for TP2)
└── TP2.long.sub109_Template (final longitudinal output TP2)

We run @SUMA_Make_Spec_FS in each of dirs:
TP1, TP2, TP1.long.sub109_Template and TP2.long.sub109_Template
Now there is a SUMA dir in each.
If we check oblique-status:
orig_data=/path/ub109-1_sT1W_do_zp_3D.nii (orignal data, deobliqued, centered, zero-padded, as above)

TP1 status: (i.e. the normal recon-all output, step1 in the long-pipeline):


3dinfo -obliquity -prefix $orig_data TP1/SUMA/wm.seg.nii.gz 
0.000	sub109-1_sT1W_3D_do_zp.nii
0.000	             wm.seg.nii.gz

And visually it looks good!

TP1.long status (i.e. the final longitudinal output, step3 in the long-pipeline) (step2 = template creation)


3dinfo -obliquity -prefix sub109-1_sT1W_3D_do_zp.nii ../sub109/TP1.long.sub109_Template/SUMA/wm.seg.nii.gz 
0.000	sub109-1_sT1W_3D_do_zp.nii
0.000	             wm.seg.nii.gz

I.e. they are not differing in oblique-ness but they still don’t match in the viewer. Does this have to do with the fact that we just delete the oblque-info and not “move” the brain like the “deoblique_refitly” option in SSwarper?

Look at the image again in my previous post:
Top of image is sub109-2_sT1W_3D_do_zp.nii overlaid with TP2/SUMA/wm.seg.nii.gz
Bottom of image is sub109-2_sT1W_3D_do_zp.nii overlaid with TP2.long.sub109_Template./SUMA/wm.seg.nii.gz

At the end of it all, it strikes me the final data should overlay either the first “T1w orig”, the second “T1w orig”, or, if the program is generating some intermediate “template”, then that space. It is hard for me to see how the datasets could not overlay one of these three possibilities (assuming the issue is not due to obliquity in the input)

Yes. This is the question. If what I provide above is proof that there is no more obliquity in the input, then it seems likely that the long.output is in template space.
I ran @SUMA_Make_Spec_FS in the sub109_Template dir as well to get some nifit-files that we know are in template space.
If I look at the generated SurfVol volume I can se a little “jack” / dark stripe at the bottom. This tells me that this really is the a merged version in a new common space of input-T1-TP1 and input-T1-TP2: Its is some kind of mean/median between the two and dark stripe at the bottom is because the time points are not cropped (we use 3dZeropad -I -70 …) in the exact same anatomical place for TP1 vs TP2. Hence only half the intensity in the non-overlap part in the upper neck.

The long-output matches this volume in AFNI for both TP1 and TP2. This suggests to me that the long.output is in template space. But I don’t know.
Image below is TP1 and TP2:s long output:
TP1.long.sub109_Template/SUMA/wm.seg.nii.gz
and
TP2.long.sub109_Template/SUMA/wm.seg.nii.gz
as overlay on sub109_Template/SUMA/Surf.vol

Sure, give me upload instructions and I’ll attach this one subject (still raw and oblique) with the two scripts you need =)

EDIT: See next post in thread. I think this is solved! But please answer the questions regarding 3drefit and SSwarper in the beginning if you can =).

I got a reply from the author of the longitudinal pipeline!

Hi Robin,
the long-processed images are all in the same space as the base image. This is -kind of- in the middle between your two time points (e.g. if the head is tilted left in TP1 and right in TP2 it will be upright) .

So if you want to use that mask in your fMRI analysis you need to register the fMRI with images from the base dir or one of the longitudinal time points instead of with the original T1 image .
Best, Martin

So yes, it all makes sense! Your fix fixed the normal recon-all. And the output ROI’s in the .long dirs are in “tempalte space” and should not overlap with the orig input data! We will use either the T1.nii.gz or SurfVol from the long.TP2 directory as SSWarper input!