Hi!

Quote

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

Quote

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?

Quote

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:

Quote

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

2) 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

3) 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

Quote

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 =).



Edited 5 time(s). Last edit at 09/03/2021 05:39AM by Robin.