images look inconsistent between AFNI and fsleyes/mrtrix

AFNI Message Board
21

Is your ROI-based analysis just with a single ROI? Or are there more?

Here is a first draft of an updated AP command. Importantly, but adding the 'regress' block, we will get an APQC HTML that is very useful for checking a lot of things, too.

I have left in the blur block for now.

Please let us know how this goes, and we can check things.

# remove obliquity from the anatomical, in a way that preserves the 
# accompanying ROI location. Typically, this is not the way I would
# deoblique it from the start (instead using adjunct_deob_around_origin)
3dcopy T1w_coreg.nii.gz T1w_coreg_REFITDEOB.nii.gz
3drefit -deoblique T1w_coreg_REFITDEOB.nii.gz

# add in a regress block, so the APQC HTML is available
#     -> and also add in basic regress block processing params, for
#        QC and reference
# mention that the anatomical does *not* have its skull
# add in an anat_follower ROI, so the sphere ends up in the final EPI 
#    grid
# add QC table info about signal strength and other properties for the
#    anat_follower ROI
afni_proc.py                                                       \
  -subj_id                  ${subj}                                \
  -copy_anat                T1w_coreg_REFITDEOB.nii.gz             \
  -anat_has_skull           no                                     \
  -anat_follower            lOPAr5 epi Fsub-05_lOPA_rad5.nii.gz    \
  -dsets                    ${subj}_fpo_run-0*+orig.HEAD           \
  -blocks                   tshift align volreg mask blur          \
                            scale regress                          \
  -radial_correlate_blocks  tcat volreg                            \
  -tcat_remove_first_trs    2                                      \
  -align_unifize_epi        local                                  \
  -align_opts_aea           -cost lpc+ZZ                           \
                            -giant_move                            \
                            -check_flip                            \
  -volreg_align_to          MIN_OUTLIER                            \
  -volreg_align_e2a                                                \
  -mask_epi_anat            yes                                    \
  -blur_size                6.0                                    \
  -regress_motion_per_run                                          \
  -regress_apply_mot_types  demean deriv                           \
  -regress_censor_motion    0.2                                    \
  -regress_censor_outliers  0.05                                   \
  -regress_est_blur_epits                                          \
  -regress_est_blur_errts                                          \
  -regress_compute_tsnr_stats lOPAr5 1                             \
  -html_review_style        pythonic                               \
  -execute

--pt

22

Hi Paul,
Thanks for this. I will try this out later today. However, just so that I am clear, I want to preserve the obliquity in the T1 data (and the EPI data) because the T1 data is aligned to the DTI data (and the goal is to align everything - T1w and the EPI to the DTI data).

I saw this command from Daniel on this message board;
3drefit -atrcopy IJK_TO_DICOM_REAL my_orig_anat+orig brain.nii

This may be what I needed. Anyway, I will try things out and report back. Thank you so much, again. - Yaelan

23

Hi, Yaelan-

I am struggling to see why it would be helpful to have obliquity in a final dataset. The obliquity information is basically a waiting-to-be-applied transform. In my view, for final data, it should either have been purged or applied. Leaving it lurking does not seem helpful, and leaves room for subtle challenges and weirdnesses, esp. when moving across software.

Does your DTI data really have obliquity in it? What is the output of:

3dinfo -obliquity DSET_DTI

?

Also, is your DTI data on the same grid as your T1 data:

3dinfo -same_all_grid -prefix DSET_DTI DSET_T1

?

There are different ways to remove or apply obliquity. Maybe you can see which of these preserves alignment to your DTI data:

# purge obliquity---need to copy first, because 3drefit changes the header
# -> does not regrid data, but might make it look shifted
3dcopy T1w_coreg.nii.gz test_v1.nii.gz
3drefit -deoblique test_v1.nii.gz

# apply the obliquity
# -> will regrid the data, hence a wee bit of blurring
3dWarp -deoblique -prefix test_v2.nii.gz T1w_coreg.nii.gz

# purge obliquity, but in a way to preserve coord origin
adjunct_deob_around_origin \
    -prefix test_v3.nii.gz \
    -input T1w_coreg.nii.gz

--pt

24

Hi Paul,

That is a good question! No, my DTI data has no obliquity! And yes, all I want and care about is to see my ROI seed region in the right spot of the brain when I go across different software. I may try deobliqueing T1 data before I align it to DTI data and see if I can live in an all-deobliqued world! Thanks so much for your input. I truly appreciate it (you have no idea!).
Yaelan

25

And, your script made it work! Thanks so much!
I uploaded the QC report on the google drive in case you are curious (of course, you don't have to check it out). I'm curious why you would not deoblique the T1 data normally as this way, but at any rate, I really appreciate your help!

26

Hi Paul, I wanted to just reply to this instead of making a whole new post. We want to do ROI and whole brain analyses on a data set we've acquired over the past year, but I'm confused on the blurring aspect of the pre-proc. Should we run two proc.py scripts (one with blurring and one without) to use for each analysis?