AFNI Message Board

History of AFNI updates  

|
March 09, 2021 05:10PM
Hi, Jenna-

I think that it is not the differing orientations, but the initial data being oblique, that explains the differences here when you process in different ways.

Running 3dresample purges the obliquity information from the dset---because there are resampling processes that would be inconsistent with the obliquity. So, then you might have an anatomical with obliquity info and a ventricle map that *doesn't* have that, and things end up in different places/spaces relatively. I would wager that is what is happening with the PC error message as well: there is no overlap because things are in a different spot.

Re. processing pipeline:
1) I run that set of programs often, and I don't worry about dset orientations. However, making sure that obliquity doesn't cause problems is a larger consideration.

2) I think the issue is that early dsets (raw anatomical) have obliquity and the derived ones after FreeSurfer (tissue maps) or resampling *don't*---that is why things don't overlap.
I generally prefer to remove obliquity information from my EPI and anatomical. There are some options how to do this:
A) "3drefit -deoblique ..." will *purge* the obliquity info, so the input dset is not regridded, and it just has the coordinates as seen in the GUI---the down side is the shopping of the coordinate matrix can leave the current coordinates far from centering the brain around (x,y,z)=(0,0,0); and since the EPI and anatomical are on different grids, they might not end up well aligned anymore even though they started out that way.
B) "3dWarp -deoblique ..." will *apply* the obliquity info, so the dset is output in scanner coordinates (which were hopefully well-centered to start). But the output dset will have been regridded-- for EPI data, this kind of extra smoothing-by-regridding is something to avoid.
C) A third option is to *remove* the obliquity information without regridding BUT preserving the location (x,y,z)=(0,0,0) in the dset; so, if your coordinates are well-centered to start, they wil remain so. And relative obliquity differences (e.g., between a subject EPI and anat) are reduced to hopefully just a minor rotation (to be overcome with the alignment step that will be done, anyways). To do this to create new NIFTI, one could do the following:
3dcopy ${dset}  tmp       # yes, copy to BRIK/HEAD
set sp = `3dinfo -av_space "${dset}"`
3drefit  -oblique_recenter  tmp${sp}
3drefit  -deoblique tmp${sp}
3dcopy tmp${sp} OUTPUT.nii

The attached image shows a comparison of these. In each case, option "B" is underlaid, because that is where the dset is in "scanner coordinates" (the downside of getting it from 3dWarp like this is a slight blurring). The crosshairs are centered at (x,y,z)=(0,0,0). In the top row, the 3drefit-style deobliquing in A is overlayed---notice how the brain is in a non-centered spot; it could certainly be further off, depending on the obliquity information. In the bottom row, the case C is shown---notice how it is still well-centered, looking mainly rotated around the coordinate origin a bit.

If useful, here is a slightly fancier script version of Case C, that I put in a script "do_deoblique_keep_000.tcsh", which takes 2 arguments-- an input and output dset (and cleans up a temporary file):
#!/bin/tcsh

# This script will purge obliquity with NO regridding, AND preserve
# where (x,y,z)=(0,0,0), so coords stay well-behaved IF they started
# well-behaved

# --------------------------------- setup --------------------------------

set narg_good = 2
set dset_in   = $1
set dset_out  = $2

set narg = ${#argv}
if ( ${narg} != ${narg_good} ) then
    echo "** ERROR: Should have ${narg_good} args input:"
    echo ""
    echo "       tcsh do_deoblique_keep_000.tcsh DSET_IN DSET_OUT"
    echo ""
    echo "   ... but only this many args have been used: ${narg}"
    exit 1
endif

set avsp     = `3dinfo -av_space "${dset_in}"`
set tpref    = tmp_1234
set dset_tmp = ${tpref}${avsp}

# ------------------------------- the work --------------------------------

3dcopy   "${dset_in}"       ${tpref}              # yes, copy to BRIK/HEAD

3drefit  -oblique_recenter  ${dset_tmp}
3drefit  -deoblique         ${dset_tmp}

3dcopy   ${dset_tmp}        "${dset_out}"

# --------------------------------- finish -------------------------------

if ( $status ) then
    echo "** ERROR: failed to copy output dset:  ${dset_out}"
    exit 1
endif

# cleanup
\rm  "${dset_tmp}".HEAD "${dset_tmp}".BRIK*

echo "++ Have deobliqued (whilst retaining coordinate origin)."
echo "   ${dset_out}"

exit 0

--pt


Subject Author Posted

Orientation of input image files to proc.py

jkblujus March 07, 2021 07:57PM

Re: Orientation of input image files to proc.py

ptaylor March 08, 2021 12:08PM

Re: Orientation of input image files to proc.py

jkblujus March 08, 2021 04:17PM

Re: Orientation of input image files to proc.py Attachments

ptaylor March 09, 2021 05:10PM



Sorry, only registered users may post in this forum.

Click here to login