3drefit -deoblique

Doughboys · November 12, 2021, 6:12pm

Hello AFNI team,

When removing obliquity from my original images (just converted DICOM to Nifti) using the command:


3drefit -overwrite -deoblique dset_anat_deob

for anatomical images (deobliquing the anatomical images before @animal_warper was advised in a previous post)

and


3drefit -overwrite -deoblique dset_func_deob

for functional images

Originally (before deoblique) dset_func_deob and dset_anat_deob were perfectly aligned (despite that they had different oblique)
After deoblique dset_func_deob appeared shifted when compared to dset_anat_deob.

3Dinfo before deoblique
Anat:


Template Space:  ORIG
Dataset Type:    Anat Bucket (-abuc)
Byte Order:      LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode:    NIFTI
Storage Space:   25,165,824 (25 million) bytes
Geometry String: "MATRIX(0.499882,0,0.010845,-63.49814,-0.004364,0.45773,0.201158,-33.41661,-0.009928,-0.201205,0.457622,-22.09527):256,256,192"
Data Axes Tilt:  Oblique (23.760 deg. from plumb)
Data Axes Approximate Orientation:
  first  (x) = Right-to-Left
  second (y) = Anterior-to-Posterior
  third  (z) = Inferior-to-Superior   [-orient RAI]
R-to-L extent:   -63.498 [R] -to-    64.002 [L] -step-     0.500 mm [256 voxels]
A-to-P extent:   -33.417 [A] -to-    94.083 [P] -step-     0.500 mm [256 voxels]
I-to-S extent:   -22.095 [I] -to-    73.405 [S] -step-     0.500 mm [192 voxels]
Number of values stored at each pixel = 1
  -- At sub-brick #0 '?' datum type is short:            0 to          1586

Func:


Template Space:  ORIG
Dataset Type:    Anat Bucket (-abuc)
Byte Order:      LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode:    NIFTI
Storage Space:   262,144 (262 thousand) bytes
Geometry String: "MATRIX(1.991842,0,0.180458,-64.53218,-0.064086,1.869635,0.70736,-17.80025,-0.168695,-0.710257,1.862009,-6.530476):64,64,32"
Data Axes Tilt:  Oblique (21.408 deg. from plumb)
Data Axes Approximate Orientation:
  first  (x) = Right-to-Left
  second (y) = Anterior-to-Posterior
  third  (z) = Inferior-to-Superior   [-orient RAI]
R-to-L extent:   -64.532 [R] -to-    61.468 [L] -step-     2.000 mm [ 64 voxels]
A-to-P extent:   -17.800 [A] -to-   108.200 [P] -step-     2.000 mm [ 64 voxels]
I-to-S extent:    -6.530 [I] -to-    55.470 [S] -step-     2.000 mm [ 32 voxels]
Number of values stored at each pixel = 1
  -- At sub-brick #0 '?' datum type is short:            0 to         28215

3Dinfo after deoblique
Anat:


Template Space:  ORIG
Dataset Type:    Anat Bucket (-abuc)
Byte Order:      LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode:    NIFTI
Storage Space:   25,165,824 (25 million) bytes
Geometry String: "MATRIX(0.5,0,0,-63.49814,0,0.5,0,-33.41661,0,0,0.5,-22.09527):256,256,192"
Data Axes Tilt:  Plumb
Data Axes Orientation:
  first  (x) = Right-to-Left
  second (y) = Anterior-to-Posterior
  third  (z) = Inferior-to-Superior   [-orient RAI]
R-to-L extent:   -63.498 [R] -to-    64.002 [L] -step-     0.500 mm [256 voxels]
A-to-P extent:   -33.417 [A] -to-    94.083 [P] -step-     0.500 mm [256 voxels]
I-to-S extent:   -22.095 [I] -to-    73.405 [S] -step-     0.500 mm [192 voxels]
Number of values stored at each pixel = 1
  -- At sub-brick #0 '?' datum type is short:            0 to           889

Func:


Template Space:  ORIG
Dataset Type:    Echo Planar (-epan)
Byte Order:      LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode:    NIFTI
Storage Space:   183,500,800 (184 million) bytes
Geometry String: "MATRIX(2,0,0,-64.53218,0,2,0,-17.80025,0,0,2,-6.530476):64,64,32"
Data Axes Tilt:  Plumb
Data Axes Orientation:
  first  (x) = Right-to-Left
  second (y) = Anterior-to-Posterior
  third  (z) = Inferior-to-Superior   [-orient RAI]
R-to-L extent:   -64.532 [R] -to-    61.468 [L] -step-     2.000 mm [ 64 voxels]
A-to-P extent:   -17.800 [A] -to-   108.200 [P] -step-     2.000 mm [ 64 voxels]
I-to-S extent:    -6.530 [I] -to-    55.470 [S] -step-     2.000 mm [ 32 voxels]
Number of time steps = 700  Time step = 0.70000s  Origin = 0.00000s  Number time-offset slices = 32  Thickness = 2.000
  -- At sub-brick #0 '?' datum type is short:            0 to         17639
  -- At sub-brick #1 '?' datum type is short:            0 to         17319
  -- At sub-brick #2 '?' datum type is short:            0 to         18897
** For info on all 700 sub-bricks, use '3dinfo -verb' **

What can I do to have dset_func_deob aligned to dset_anat_deob after deoblique?

Clem

Doughboys · November 12, 2021, 7:45pm

I got it!

So for future users,
just do:


3dWarp -overwrite -gridset dset_bold_deob -oblique_parent anat -prefix dset_bold_deob dset_bold_deob

before


3drefit -overwrite -deoblique dset_func_deob

anat being dset_anat_deob before deboblique

Cheers,
Clem

ptaylor · November 12, 2021, 7:54pm

Hi, Clem-

To be clear, “3drefit -deobllique …” will purge obliquity information from a dset: the input dset is overwritten, and the obliquity information is removed—it will appear in the same place in the GUI, too. The data is not resampled/regridded, so it is not blurred at all.

“3dWarp -deoblique …” will apply the obliquity information, so the new output data will not have obliquity, but it will appear in a different spot in the GUI—it should be in the spot where the obliquity information had placed it. In this case, the data is resampled/regridded, though, so it will get a bit blurred.

–pt

Doughboys · November 12, 2021, 8:24pm

my previous misunderstanding makes sense now!
Is my correction with “3dWarp -oblique_parent” ok?
or is it a problem to blur a little bit the functional before passing it into afni_proc.py?
Do I have another solution? Can I concatenate the difference of obliquity directly with the WARP or AFF included in afni_proc.py to not accumulate multiple transformations?
or should I not do “3drefit -deoblique” at all on both dataset?
thank you!

ptaylor · November 12, 2021, 8:50pm

There are lots of options here, but what makes most sense depends on what your goals are.

If you are going to put these datasets into afni_proc.py, I would try to avoid regridding either, but most importantly not the EPI (regridding the anatomical is probably less of a concern).

If you want to get rid of obliquity without regridding and have the dsets be pretty well aligned, you could do the following on each to remove the obliquity information while preserving the location of the coordinate origin in the dset, where (x,y,z)=(0,0,0):


3dcopy DSET_ORIG tmp
3drefit -oblique_recenter tmp+orig
3drefit -deoblique tmp+orig 
3dcopy tmp+orig DSET_NEW

The dsets should be quite close to still aligned, if there wasn’t a huge amount of relative obliquity between them originally.

Note the use of 3dcopy initially, because 3drefit changes header information. And also note that “tmp*” should be a BRIK/HEAD file, as here.

–pt

Doughboys · November 12, 2021, 9:53pm

thank you that works fine!
final question, supposed that I modified in a second step the origin of dset_anat_deob to fit the template


3dCM -set 0 0 0 dset_anat_deob

and measure the transfo as Anat_rs_tshift_deob_RECEN.1D

to realign dset_bold_deob I do:


@Align_Centers -overwrite -base dset_anat_deob -dset dset_bold_deob -prefix BOLD_rs_tshift_deob_RECEN.nii.gz -shift_xform_inv Anat_rs_tshift_deob_RECEN.1D

since I only apply an AFF it shouldn’t blur or regrid the dset_bold_deob? right?

ptaylor · November 12, 2021, 10:18pm

I’m afraid I don’t understand what you are asking. Could you please reformulate the question.

–pt

Doughboys · November 12, 2021, 10:25pm

Sure, to make it simple

if modify the center of a functional image with


@Align_Centers -overwrite -base dset_anat_deob -dset dset_bold_deob -prefix BOLD_rs_tshift_deob_RECEN.nii.gz -shift_xform_inv Anat_rs_tshift_deob_RECEN.1D

this is not going to create regrinding issues? since I am just translating the center of the image?

ptaylor · November 12, 2021, 10:36pm

That is correct; that command is just changing header information (about coordinates), not regridding data.

–pt

Doughboys · November 22, 2021, 9:09pm

Hello Paul,

I have a new question, sry,

suppose that I need to reverse the command


3dcopy DSET_ORIG tmp
3drefit -oblique_recenter tmp+orig
3drefit -deoblique tmp+orig 
3dcopy tmp+orig DSET_NEW

in order to send an atlas in DSET_NEW space back to ORIG space (DSET_NEW to DSET_ORIG space).
Basically reversing the deoblique and oblique_recenter
What would be the command?

Thank you
Clément

dglen · November 22, 2021, 9:23pm

Information is lost inside the dataset itself with these refits. You would have to copy the relevant attributes from the original dataset. For example, for an oblique or a NIFTI dataset, you can do this to restore the oblique transformation attribute in the header.

3drefit -atrcopy IJK_TO_DICOM_REAL original_dset modified_dset

Doughboys · November 24, 2021, 6:27pm

Sorry, to come back to you,
The all co-registration process just ended for all monkeys
it seems that the command


3dcopy DSET_ORIG tmp
3drefit -oblique_recenter tmp+orig
3drefit -deoblique tmp+orig 
3dcopy tmp+orig DSET_NEW

works for some of the data but creat misregistration for others by not aligning correctly “DSET_NEW” functional image and “DSET_NEW” anatomical image.
Should I just abandon purging the obliquity?

Thank you
Clem

ptaylor · November 24, 2021, 9:14pm

Hi, Clem-

If your EPI and anatomical truly overlap exactly/closely in the coordinates stored in the header, when the obliquity is applied then this set of steps should lead to close alignment (but probably not exact, due to different grids) between the “new” EPI and anatomical dsets.

If this leads to bad initial alignment between the new anat and EPI, then I would guess that the actual datasets probably don’t line up well to start with.

You could check this assertion by running the following to apply the obliquity information to both the EPI and anatomical dsets:


3dWarp -deoblique -prefix ANAT_DEOB.nii.gz [anat dset]
3dWarp -deoblique -prefix EPI_DEOB.nii.gz [epi dset]

… and check the overlap of ANAT_DEOB.nii.gz and EPI_DEOB.nii.gz. If those don’t line up well (as I suspect they won’t), then the coordinate problem is inherent to your dsets from the get-go. If those do line up well, then, well, I’d like to see a pair of those to see what might be happening.

–pt

Doughboys · November 24, 2021, 9:35pm

Thank you pt,
I have run your command,
they do align perfectly =(
I can send you a few examples if you want, no problem
Do you prefer a link or do you need to send me a repository link? How many images do you need?

ptaylor · November 24, 2021, 10:19pm

Okeydoke then…

I’ll send you a box drive, just one example pair should be good to start.

–pt

ptaylor · November 25, 2021, 2:22am

OK, thanks for sharing the data.

The problem is that the coordinate origin (x, y, z) = (0,0,0) is far outside the brain for the dsets. So, preserving that spot in each FOV while deobliquing doesn’t help preserve the relative brain overlap. Because the max angle of obliquity is so different between the dsets (16 deg and 0.2 deg), they get torqued differently.

–pt

Doughboys · November 25, 2021, 4:44pm

thank you for your answer!
What do you think is my best options here?
-Recenter the brain to (x, y, z) = (0,0,0) and then -deoblique?
-Abandon deoblique, it is creating more problems than it solves?
-Something else?

ptaylor · November 26, 2021, 2:42pm

Having (x,y,z)=(0,0,0) in a reasonably central location should pretty much always be a good idea. Having pretty good alignment between the EPI and anatomical is generally helpful, too. Getting rid of obliquity considerations at the same time… priceless (well, at least it is mildly helpful).

This should accomplish the above for the dset you shared, methinks:


#!/bin/tcsh

set dset_orig = DSET_ANAT
set dset_new  = anat_ctr.nii

3dcopy $dset_orig $dset_new
3dCM   -set 0 0 0 $dset_new

set dset_orig = DSET_EPI
set dset_new  = epi_ctr.nii
set dset_mask = epi_mask.nii

# get a mask well-approximating where the brain is in the EPI
3dAutomask             \
    -prefix $dset_mask \
    $dset_orig

3dcopy $dset_orig $dset_new
3dCM   -mask $dset_mask -set 0 0 0 $dset_new

–pt

Doughboys · November 26, 2021, 7:00pm

thank you pt,
If I understand correctly, 3dCM will still create some minor misalignment on the anat and on the BOLD due to the differences in the calculation of the center of mass (mask for fMRI, without or with a different mask for the anat).
I have done something similar to what you proposed and these little misregistrations had impacted somehow the precision of fMRI co-registration (I have got a very poor SNR in the BOLD…)

In my case, deobliquing seems to create more problems than it solves (not so priceless in the end)

Also, I need to be able to send some atlases, back in the original space (the question that Daniel answer)
and for some random reason, it seems to not work well either =(

Given the number of problems it creates:
What would be the consequences of keeping the obliquity?
Is it that bad if I choose to do the analysis with the obliquity?

Thank you,
Happy Thanksgiving by the way =)

Doughboys · November 29, 2021, 4:31pm

hello pt

I pushed a little bit my analysis

I confirm that the remaining differences of brain orientations using 3dCM (between anat and bold) create misalignment when using afni_proc.py in a second time.
I tried to not deboblique the anat and to just use 3dCM prior to @animal_warper. This was a huge fail since I realize that 3dCM and @Align_Centers are actually doing deboblique by default…
I am still currently trying to align the bold_deob and anat_deob but without success

I am still confused about how the information of deoblique angle (or/and center?) is lost in the process.

Any other thoughts on what is my best option for this analysis?
trying align_epi_anat.py? but it is already by default in afni_proc.py…

Is there absolutely no way to have to anat_deob match bold_deob other than aligning masks?
A way to calculate the differences/error of oblique/center between anat_deob and bold_deob?

for info: the command afni_proc.py that I am trying to run


afni_proc.py -subj_id Unity2021_03_18 -script                                                                                \
     Unity2021_03_18/proc.Unity2021_03_18                                                                                   \
     -scr_overwrite -out_dir                                                                                                                 \
     Unity2021_03_18/Unity2021_03_18.results                                                                                \
     -blocks tshift align tlrc volreg blur mask regress -dsets                                                                \
     Unity2021_03_18/BOLD_restingstate_deob.nii.gz                                                                       \
     -copy_anat                                                                                                                                    \
    Unity2021_03_18/anatT1_deob.nii.gz                                                                                           \
     -anat_has_skull no -align_opts_aea -cost lpc+zz -check_flip -giant_move                                   \
     -epi_strip 3dAutomask -align_epi_strip_method 3dAutomask -mask_dilate 1                              \
     -volreg_align_to MIN_OUTLIER -volreg_tlrc_warp -mask_epi_anat yes                                      \
     -tlrc_base                                                                                                                                       \
     Unity2021_03_18/anatT1_deob_in_stdy_template.nii.gz                                                              \
     -tlrc_NL_warp -tlrc_NL_warped_dsets                                                                                           \
     Unity2021_03_18/anatT1_deob_in_stdy_template.nii.gz                                                               \
     Unity2021_03_18/1Dconcat.1D                                                                                                      \ 
     Unity2021_03_18/concate_WARP.nii.gz                                                                                         \
     -regress_motion_per_run -regress_apply_mot_types demean deriv                                              \
     -blur_size 3 -mask_import WMa                                                                                                      \
    atlas_to_study_template/WM2mm.nii.gz                                                                                          \
     -regress_make_corr_vols WMa -regress_anaticor_fast                                                                   \
     -regress_run_clustsim yes -regress_est_blur_errts -html_review_style                                           \
     pythonic -execute -tcat_remove_first_trs 5

Sorry about that,

Clem

PS:
My apologize to Daniel, the command is working fine


3drefit -atrcopy IJK_TO_DICOM_REAL original_dset modified_dset

except that it seems that atrcopy is requiring something like that


3drefit -atrcopy original_dset IJK_TO_DICOM_REAL original_dset modified_dset

my viewer (ITKsnape) was doing some crap in addition to that… that is why I was thinking that it was not working