How to improve 3drefit’s deoblique results?

[Philipp]

Hello,

I have a dataset with very oblique functional runs for almost all subjects. The first/upper image below shoes the original (raw data) anatomical-functional overlap.

Then, I ran 3drefit on both the anatomical and functional scans as follows:

3dcopy $directory_raw/anat/T1w.nii.gz Temporary
3drefit -oblique_recenter Temporary+orig
3drefit -deoblique Temporary+orig
3dcopy Temporary+orig Anat_deoblique
rm Temporary+orig.BRIK
rm Temporary+orig.HEAD

3dcopy $directory_raw/task/task.nii.gz Temporary
3drefit -oblique_recenter Temporary+orig
3drefit -deoblique Temporary+orig
3dcopy Temporary+orig Task_deoblique
rm Temporary+orig.BRIK
rm Temporary+orig.HEAD

The second image below shows the new anatomical-functional overlap for the same subject after running the code above. It looks better, but the overlap is still not nice. I get these bad results for most of the subjects.

Question: What further options are recommended to improve the overlap berfore I start preprocessing the data with AFNI proc? I would like to get a nicer overlap first, since the functional run is still kinda oblique even after running 3drefit.

[ptaylor]

Hi, Philipp-

When you say that you get “bad results”, what does that mean—if you put your recentered data into afni_proc.py, is the EPI-anatomical alignment not good (ve2a block), or is the anatomical-template alignment not good (va2t block)?

Note that what those sets of commands are doing is purging obliquity from the header while preserving the location of the coordinate origin. It is possible one or both dsets will appear at an angle to the FOV bounds still, if that is the initial angle was in the original data (which it appears to be here). It would be expected that the EPI-anatomical alignment won’t necessarily be perfect, but the idea is that:

1. the obliquity is removed from the dsets (which different software/programs treat differently)
2. the removal does not blur the data at all (only the headers are affected, not the datasets themselves)
3. the obliquity removal preserves coordinate origin, so that
   A) datasets that are semi-centered around (x,y,z)=(0,0,0) stay that way (helping anatomical-template alignment), and
   B) datasets that are semi-aligned to each other remain so (helping EPI-anatomical alignment).
   It is not expected/necessary that there is absolute alignment between the EPI and anatomical, esp. if there was a relative obliquity difference between them to start with, which I suspect there was here since the underlying anatomical doesn’t appear to be changed by the deobliquing procedure (not a problem at all, just noting).

It also appears like the EPI brain was acquired with an angle between the “main” brain axes and the oblique acquisition slices. This procedure will not “undo” that, inherently, because the dataset won’t be regridded and interpolated.

So, in summary, I am not sure there is a problem here, but please let us know if, say, afni_proc.py is failing for this data? The “new.jpg” image actually looks like pretty good initial alignment, esp. for a very obliquely acquired EPI.

-pt

[Philipp]

Hi Paul,

@When you say that you get \"bad results\"

By “bad results” I refered to the new or lower image attached, that is, the result of 3drefit (and not a preprocessed result by AFNI proc).

I remember that when I previously ran AFNI proc on such “bad” anatomical-functional overlaps, I often got bad or simply messed up alignment results from AFNI proc. Then, I ran the same 3drefit script as shown above (you helped me here long ago, suggesting to run this script), which resulted into a really nice anatomical-functional overlap.

However, this time the functional scan still looks so oblique after running 3drefit. In fact, even after running 3drefit the oblique degree looks almost like before, as if I only ran

 -oblique_recenter

but not

-deoblique

Thats why I aimed to a get good overlap before running AFNI proc at all (I did not even run AFNI proc yet).
So thanks for your answer, I did really not expect that this overlap result by 3drefit can be good enough for proper preprocessing (which I will try out after SSwarper is ready and then probably report back here in case I face further problems that I cannot solve on my own).

One more question:
Some subjects’ raw anatomical and functional scans are in +orig space, while others are in +tlrc space. I considered that in the 3drefit script by simply changing the code lines to +orig or +tlrc, depending on the subject. Next, I would feed the results of 3drefit to SSwarper and subsequently to AFNI proc. Does AFNI proc handle both the +orig and +tlrc files fine, or do I have to apply @auto_tlrc on the +orig subjects even before running SSwarper and AFNI proc?

[ptaylor]

Hi, Philipp-

I don’t quite agree with the “bad” designation here. Again, to me the new.jpg looks pretty good. Also note that this deobliquing will not unrotate the dataset relative to its acquired image axes—this EPI appears to have been acquired with standard brain slices at an angle to the FOV bounds, and they will stay there.

And actually, since the anatomical does not appear to have any obliquity, I think you actually don’t need to deoblique the EPI at all—during processing, the obliquity will be applied as the alignment starts. So, that should be fine, and perhaps even desired, given the relative angle of the EPI. Let afni_proc.py handle it, assuming that when the EPI obliquity is applied, the EPI-anatomical alignment is good—which could be verified by checking the output of this on the original EPI and anatomical:

@djunct_overlap_check \
 -ulay DSET_ANATOMICAL \
  -olay DSET_EPI \
  -prefix img_epi_anat_olap

You should get 2 images out—one ignoring obliquity (which might show poor alignment in the image) and one applying all obliquity (which might/should show good alignment). As long as:

1. your anatomical does not have obliquity (“3dinfo -obliquity DSET_ANAT” is 0.00)
2. original EPI-anatomical overlap in the image that applies obliquity looks good
   … then you would be good to go without doing those deobliquing steps.

–pt

[Philipp]

Hi Paul,

here is the output of

@djunct_overlap_check \
 -ulay DSET_ANATOMICAL \
  -olay DSET_EPI \
  -prefix img_epi_anat_olap

for the same subject that I showed before. Please see the first attached image. I am not sure if that overlap is good enough. The problem is that AFNI proc alignment fails (note that the SSwarper results are really clean and nice, so the problem is not comming from badly processed skullstripping).

Another problem is the following message while preprocessing the subject with AFNI proc:

*+ WARNING: Input dataset is not 3D+time; assuming TR=1.0

I know that this is a “standard” output by AFNI proc that can normally be ignored. And in previous datasets that I preprocessed, the final TR that is stated at the end of the index page (I am talking about the quality control output file by AFNI proc) showed the real TR of the dataset, for example TR = 1, or TR = 2.0, etc. But with this dataset, the index QC page shows me a TR of 1 after preprocessing, even though the real TR of that dataset is 2.27.

I then checked the TR via 3dinfo of the functional raw data, and the functional raw data inded has a TR of 1, even though that is wrong. Would it be fine shifting the TR to 2.27 via 3drefit in the previously shown code that I also use to deoblique the functional runs?

Yet another potential problem I have never seen before is the following output in the index file:

EPI variance lines warnings
Lines per run : 1

Coordinates (check locations with InstaCorr)
--------------------------------------------
          r01          
-----------------------
 -57.70   12.80    6.40

Can this be ignored, or is that relevant?

Here is my AFNI proc script. This is a resting-state run. I previously ran it with “lpc+ZZ” (instead of lpa) and without “-align_unifize_epi local”, but the results looked messed up in both cases. I attached you screenshots for both results.

afni_proc.py \
-subj_id ${subject}_EoEc \
-out_dir $directory_run/Results \
-dsets \
	$directory_deoblique/Eo-Ec_deoblique+orig \
-blocks despike tshift align tlrc volreg mask blur regress \
-copy_anat $directory_sswarper/anatSS.$subject.nii \
-anat_has_skull no \
-tcat_remove_first_trs 4 \
-align_opts_aea -cost lpa -big_move \
-align_unifize_epi local \
-volreg_align_e2a \
-volreg_align_to MIN_OUTLIER \
-volreg_tlrc_warp -tlrc_base MNI152_2009_template_SSW.nii.gz \
-tlrc_NL_warp \
-tlrc_NL_warped_dsets \
	$directory_sswarper/anatQQ.$subject.nii \
	$directory_sswarper/anatQQ.$subject.aff12.1D \
	$directory_sswarper/anatQQ.${subject}_WARP.nii \
-volreg_post_vr_allin yes \
-volreg_pvra_base_index MIN_OUTLIER \
-mask_segment_anat yes \
-mask_segment_erode yes \
-regress_anaticor \
-regress_ROI WMe CSFe \
-regress_apply_mot_types demean deriv \
-regress_motion_per_run \
-regress_censor_motion 0.3 \
-regress_censor_outliers 0.15 \
-blur_size 8.0 \
-regress_est_blur_epits \
-regress_est_blur_errts \
-html_review_style pythonic \
-execute

Thanks for any help.

Update:
I used 3drefit to change the TR from 1.0 to 2.27 before running deoblique on the functional raw data. The EPI variance lines warning no longer appears after preprocessing the first subject with AFNI proc. However, alignment still fails. I already tried out the lpa, lpc+zz, and nmi cost functions.

Update two:
Simply running the following alignment options

-align_opts_aea -cost lpc+zz -giang_move \
-align_unifize_epi local \

did the job. Hence, -giant_move instead of only running -big_move was required here. Sometimes the solutions are easier than I thought…

[ptaylor]

Hi, Philipp-

Focusing first on the img_epi_anat_olap.jpg: what EPI did you input there? Your DSET_EPI should be the “raw” or non-deobliqued one—the one that still has obliquity information—and then the output image of interest should be called img_epi_anat_olap_DEOB.jpg (created by “deobliquing” the dataset in the sense of applying the obliquity information).

From these images, including the APQC HTML ones after afni_proc.py, it appears that you are not use the original EPI datasets that I was suggesting should be used here, because the EPIs don’t have obliquity information in them still.

For most EPI-anatomical alignment in afni_proc.py, one would not find benefit from using the lpa cost function—that is useful when the datasets have similar contrast to each other. But again, I think that a different EPI dataset should be used here—the one that still has its original obliquity (so, if “3dinfo -obliquity DSET_EPI” is nonzero, in your case).

–pt

[Philipp]

Hi,

thanks and you are right, I made a mistake. Here is the anatomial-functional overlap between raw T1 and raw EPI.
The image shows the output of @djunct_overlap_check.

# ulay         = t1w.nii.gz
# ulay_is_obl  = 0
# ulay_obl_ang = 0.000
# mat44 Obliquity Transformation ::
      1.000000     -0.000000      0.000000       0.000000
      0.000000      1.000000      0.000000       0.000000
      0.000000     -0.000000      1.000000      -0.000015
# 
# olay         = task-eoec_bold.nii.gz
# olay_is_obl  = 0
# olay_obl_ang = 0.000
# mat44 Obliquity Transformation ::
      1.000000      0.000000      0.000000      -0.000015
     -0.000000      0.731354      0.681998      86.335541
      0.000000     -0.681998      0.731354     -14.266663

The output of

3dinfo -obliquity task-eoec_bold.nii.gz

is 43.000

[ptaylor]

Hi, Philipp-

Great, thanks. That shows your initial overlap, with your anatomical (that has no obliquity) and the EPI with its original obliquity applied. That is a reasonable starting point for alignment. I would put those datasets into afni_proc.py, sticking with the “lpc+ZZ” cost function for EPI-anatomical alignment.

Going back to the original point, you typically start an FMRI input with an anatomical dset and one or more EPIs.

• If the anatomical has obliquity, it will generally be useful to use those few lines to get rid of it from the start (preserving the original location).
  • in some cases, one might just deal with the anatomical’s obliquity considerations by initially applying the obliquity with “3dWarp -deoblique …”, but the downside of that is that the image will become inherently/slightly blurred in the regridding process, hence the preferred step of deobliquing without regridding but preserving coordinate origin.
• But if the EPI has obliquity, which is more common, you should generally be OK leaving it in. afni_proc.py will deal with it appropriately internally (applying the obliquity as needed).
• using @djunct_overlap_check can quickly verify that initial overlap will be OK (or not)
  • if neither input has obliquity, only one image is output, and check that initial overlap/alignment for reasonableness
  • if either input has obliquity, then 2 images are output: one ignoring obliquity values, and one applying all of them (the DEOB one). The DEOB one would be the one to focus on for judging alignment/overlap quality.

–pt

[Philipp]

I am very surprised that AFNI proc can or should handle the oblique functional runs without previously applying 3drefit’s -deoblique and -oblique_recenter options. Thats because in the past I often faced alignment problems with such oblique datasets. But I will try it out right now, only applying 3drefits TR option to change the TR. Thanks for your help so far!

[ptaylor]

NB: this conversation took a turn to another topic, so I split the thread and it continues here:
https://afni.nimh.nih.gov/afni/community/board/read.php?1,169045,169045#msg-169045

–pt

[Philipp]

The preprocessing by AFNI proc is now ready and the alignment results look good. Regarding alignment, I used the raw functional scans as suggested by you and the following options:

-align_opts_aea -cost lpc+zz -giant_move \
-align_unifize_epi local \

Two more question came up.

Question 1:
When checking the “MNI152 2009 template SSW.nii.gz” underlay vs. “full_mask.subject…” overlay, I see that the EPI functional mask does not perfectly match the MNI152 template. I assume that the result is still good enough, because the underlay is the original MNI152 brain, and not the aligned anatomical brain by the respective subject. Hence, this overlap cannot be perfect anyway. Is that correct?

The first attached image shows what I am talking about, and MNI152 template vs. full_mask comparison looks more or less the same as the one shown here for all subjects.

Question 2:
Three of twenty subjects gave me “EPI variance lines warnings” in the QC index by AFNI proc. I wonder if that is related to the fact that I manually set the TR before preprocessing the data with AFNI proc, or if that problem is related to something else? I attached a second image for this problem.

[ptaylor]

Hi, Philipp-

Thanks for the alignment update, and glad to hear things are looking good! Yes, those options:

-align_opts_aea -cost lpc+zz -giant_move \
-align_unifize_epi local \

… and probably ones I would consider default for human FMRI processing.

Re. Q1: The little “missing” bits around the edges typically reflect signal dropout and loss in the original EPI. Life is hard with EPI, and near airpockets and some boundaries the signals can be strongly affected—those regions will often have much lower signal/TSNR than the more central brain, and hence that kind of pattern is relatively common. You can often see this occuring in the original EPI if you look at those locations. Looking at the ve2a map is particularly illustrative, since you can see the extent and locations of the anatomical brain, which don’t suffer from that kind of dropout, more easily for reference.

Re. Q2: This is a pretty new check we have put in, because a few datasites had a particular kind of artifact that appeared as a vertical column of high variance in the EPI signal. In your case, this looks like a “false positive” at the edge of the mask, so I wouldn’t worry. A more “true positive” would look like a bright line running up and down the image, connecting the two red dashes (or at least appearing brightly and narrowly between a large chunk of space between them). Certainly good to ask about, but should be fine here.

-pt

[Philipp]

Hi Paul,

Question 1: Thanks for the clarification. I was already thinking if that might be an issue due to the typical signal dropout in T2 fMRI scanning.

Question 2: You wrote that “In your case, this looks like a “false positive” at the edge of the mask”. This is good to know because in the three subjects where this problem occured, it always showed up at the very side of the brain (and not somewhere in the brain) and without showing bright lines between the red dashes.

Thanks again for the support and I wish some good or relaxing christmas days soon.

[ptaylor]

Thanks, Philipp! And have a good holidays there, too.

–pt