I ran @SSwarper on about 30 participants, and most of them (~20) came out with frontal clipping after skull stripping. I tried using “-SSopt ‘-push_to_edge’” but the clipping still occurred. Any suggestions? Data from these participants had previously been processed the old way with linear warping using 3dSkullStrip from afni_proc.py, and this issue didn’t occur. My command is below. I don’t know if this is noteworthy either, but they are adolescent participants. I’ve tried running them both on our analysis cluster, which has afni version 20.0.19, and on my machine with version 20.0.24.
Hmm, I actually noticed something like this with another dset that I had recently processed; would you mind uploading one of these subjects so I can check it out? I don’t think the “push to edge” will do anything; I think it might have to do with the coords/origin and FOV of the original dset. (It happened specifically when using the TTN27 template, as you are using, and not the MNI one-- not to say that you should switch templates, but more that there is some quirk here.)
I will PM you instructions for uploading an anatomical, if that’s cool.
A large portion of the anatomical image is missing after second pass skull-stripping (see attachments). Any ideas of what might be causing this?
The first pass skull-stripping seems fine. What is the difference between the first and second skull-stripping? Would it be acceptable to feed “anat.S” instead of “anat.SS” to the afni_proc?
see the attached “pre-and-post*png,” where the TT_N27 is always underlaid, and the top row shows your dset initially (overlaid), and the bottom row shows after @Align_Centers (overlaid).
After running your same @SSwarper command, there is no “chopping” of the result (see QC_anatQQ*jpg, also attached).
that looks a bit different than what was happening in the first case in this thread-- though the solution might be the same. Please see my new reply to that thread.
Basically, my guess is that your dset starts out far from overlapping on the template dset; you can check this with:
… and then overlay that dset on your base (MNI152_2009_template_SSW.nii.gz)
In your particular case, I think this happens because of purging the obliquity information with “-deoblique_refitly”.
You could deoblique your anatomical with 3drefit, and then use a similar @Align_Centers command to what I used above. Note that removing the obliquity information might mean that your anatomical and EPI don’t align well…
Does your anatomical dset actually have obliquity? What is the output of:
Hi Paul, chiming in here (Irene and I are form the same lab and we are using the script we ended up with after my last thread). If I remember correctly we talked about how to handle obliquity. I used one of your options from here, i.e. purging the obliquity information.
Firstly I attach a print of the tempalte with test_copy.nii as the overlay generated by:
The typical output for me when running the same script as Irene is that the datasets below are clipped (seem to be same are as my first attachment):
anatSS
anatSS_al_junk
anatSS_flip_al_junk
anatSS_unflipped
anatSS_unflipped_ob
anatSS_unflipped_ob_temp_al_junk
While these look fine (including anat_final)
anatQQ
anatSS_unflipped_ob_al_junk_wtal
anat_final
follow_anat_anat_w_skull
anatQQ_WARP.nii
stats
Attaching anat _final and anatSS side by side (all of the top dsets look like the anatSS).
I think Irene hade the clipping in the anat_final as well. But how come all those top dsets beeing clipped does not affect the anat_final (in my case)?
Where we use our raw t1.nii data and the MNI157_2009_SSW.nii tempalte (right?).
EDIT: The pre-center solved the clipping in my dataset. But I still wonder why anat_final was OK before even though all of these:
anatSS
anatSS_al_junk
anatSS_flip_al_junk
anatSS_unflipped
anatSS_unflipped_ob
anatSS_unflipped_ob_temp_al_junk
Where clipped
Yes, the T1 and the template did not overlap (see A in the attachment).
In your particular case, I think this happens
because of purging the obliquity information with
"-deoblique_refitly"
You could deoblique your anatomical with 3drefit,
and then use a similar @Align_Centers command to
what I used above. Note that removing the
obliquity information might mean that your
anatomical and EPI don't align well...
The overlap improved after running the commands you suggested (see B in the attachment). These are the commands I've run:
3drefit -deoblique T1_copy.nii @Align_Centers -cm -prefix T1_new.nii -dset T1_copy.nii -base MNI152_2009_template_SSW.nii.gz
However the anat_SS is still not looking ok (see C in the attachment). This is the command I've run: @SSwarper -input T1_new.nii -base MNI152_2009_template_SSW.nii.gz -subid sub02 -giant_move -odir .
The skull-stripping for this participant looked pretty good when using @NoisySkullStrip (see D in the attachment). Would it be at all possible to feed a skull-stripped brain to @SSwarper?
Thank you so much! Just tried this out on a different participant, and it definitely seems to be solving the problem. Thank you for restoring our frontal lobes.
It seems that using @Align_Centers with no deobliquing either at 3drefit or @SSwarper resulted in good skullstripping and alignment.
Attached are screenshots from the index.html files using the first setting vs the current one.
The first setting used (see A in attachments) : @SSwarper -input {T1_data} -base MNI152_2009_template_SSW.nii.gz -deoblique_refitly -subid {sub_id} -giant_move odir .
I got very similar results when using the following scripts (see previous post for details) :
3drefit -deoblique T1_copy.nii @Align_Centers -cm -prefix T1_new.nii -dset T1_copy.nii -base MNI152_2009_template_SSW.nii.gz @SSwarper -input T1_new.nii -base MNI152_2009_template_SSW.nii.gz -subid ${sub_id} -giant_move -odir .
The new setting uses: (see B in the attachments): @Align_Centers -cm -prefix T1_new.nii -dset T1_copy.nii -base MNI152_2009_template_SSW.nii.gz @SSwarper -input T1_new.nii -base MNI152_2009_template_SSW.nii.gz -subid ${sub_id} -giant_move -odir .
It looks like for both sub05 (which had very poor skullstripping using the first script) and sub09 (which had good skullstripping using the first script) the skullstripping and alignment is improved, when using the new setting.
The data we’re using is oblique. Could you help me in understanding why the results are better when not using deoblique?
Would you be able to upload the dataset? Sending the pictures is helpful, but I think it would be easiest if I could just browse through it more fully.
Thanks for uploading the dset, and I think the issue is resolvable as follows:
So, the issue here mainly involves the fact that in both oblique and scanner coords, the location where (x,y,z)=(0,0,0) is far outside the brain; crosshairs in the attached images show this location in each coordinate case. This makes it difficult for getting the initial alignment started well (and later creates a particular memory problem with the underlying nonlinear warping problem, which creates a grid to cover both the source and base volumes).
Of a few different options, I tried to do the following get the coords off to a better starting point— as a first step, I wanted to remove a lot of the non-brain material in the inferior part of the iamge; you can either apply the obliquity matrix and do it, or just ignore the obliquity matrix and do it. I think either works pretty well. These are one set of commands, of the “ignore obliquity” variety-- it is ignored tacitly, because the output of 3dZeropad just won’t contain the obliquity matrix:
# get rid of soooooo muuuuuuch spaaaace below brain: reduce memory
# consumption, and allow for better center of mass location later
3dZeropad -I -70 -prefix T1_zp.nii T1.nii
# set center of mass to spot in brain
3dcopy T1_zp.nii T1_zp_cm.nii
3dCM -set 0 0 0 T1_zp_cm.nii
@SSwarper \
-input T1_zp_cm.nii \
-odir TEST3 \
-base MNI152_2009_template_SSW.nii.gz \
-subid sub-000
The one downside of this is, that if the EPI image has the same coords as the original anatomical, now these two dsets will start further from each other for their alignment; so a more general strategy would involve moving the EPI in a similar way (there, we would want to make sure not to regrid it). We are working on a way to deal with multiple datasets and possible obliquity better, but it is a hard thing to generalize.
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.
