3dZcutup might assume RAI orientation for all data

AFNI Message Board
1

Hi,
I am trying to use 3dZcutup to cut slices of a dataset which happens to be saved in ASR orientation. As I supply the range of slices to keep to the command, it tells me that my slice indices pass the number of slices while it does not. Apparently the slice count i this case is in R-L direction. So I suppose 3dZcutup just assumes data is saved such that the last dimension is z dimension.
Can this be fixed?

In addition to this: can you make the program able to cut in any directions? One function that achieves all what 3dYcutup or 3dXcutup would do would be great.

Further related to this: I am using align_anat_epi.py instead of afni_proc.py but I am curious of what is the recommended way to deal with master grid when aligning EPI and anat and when the origin of anatomical and EPI data are off by a lot? Using -master_epi SOURCE in this case might cause cut-off of some of the brain but using BASE could waste a lot of empty space in the grid (typically there are more non-brain stuff in the anatomical image on the bottom). This is why I am trying to cut slices in z-dimension after aligning.

Thanks!
Mingbo

2

Hi Mingbo,

I just tested this by resampling to ASR and running
3dZcutup and it worked well. Would you please
provide your exact command, along with the output
from 3dinfo (no HISTORY is needed)?

To cut in other directions, is it good enough to
run 3dresample -orient first? That is what I just
did.

If the centers are far off, consider fixing that
by running @Align_Centers before align_epie_ana.py.

  • rick
3

Hi Rick,
Thanks! Here is the command I used:

3dZcutup -keep 29 101 -prefix topup2.5GRAPPA_iout_alzc.nii topup2.5GRAPPA_iout_al+orig.
++ 3dZcutup: AFNI version=AFNI_16.1.25 (Jun 15 2016) [64-bit]
*** -keep 29 101 goes past last slice 69

The 3dinfo output of the dataset is below:

3dinfo topup2.5GRAPPA_iout_al+orig.
++ 3dinfo: AFNI version=AFNI_16.1.25 (Jun 15 2016) [64-bit]

Dataset File: topup2.5GRAPPA_iout_al+orig
Identifier Code: XYZ_aM1OgtPY9K9_dyDMcrjzAg Creation Date: Mon Jun 27 14:35:21 2016
Template Space: ORIG
Dataset Type: Anat Bucket (-abuc)
Byte Order: LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode: BRIK
Storage Space: 17,478,720 (17 million [mega]) bytes
Geometry String: “MATRIX(0,0,2.5,-86.25,2.5,0,0,-149.7524,0,-2.5,0,113.303):102,102,70”
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Anterior-to-Posterior
second (y) = Superior-to-Inferior
third (z) = Right-to-Left [-orient ASR]
R-to-L extent: -86.250 [R] -to- 86.250 [L] -step- 2.500 mm [ 70 voxels]
A-to-P extent: -149.752 [A] -to- 102.748 [P] -step- 2.500 mm [102 voxels]
I-to-S extent: -139.197 [I] -to- 113.303 [S] -step- 2.500 mm [102 voxels]
Number of time steps = 6 Time step = 8.00000s Origin = 0.00000s
– At sub-brick #0 ‘#0’ datum type is float: -198.612 to 3700.47
– At sub-brick #1 ‘#1’ datum type is float: -198.242 to 3764.38
– At sub-brick #2 ‘#2’ datum type is float: -210.951 to 3730.53

4

The 3dinfo text shows the right to left slice
direction information as:

R-to-L extent: -86.250 [R] -to- 86.250 [L] -step- 2.500 mm [ 70 voxels]

So there are 70 slices, indexed 0 to 69.

  • rick
5

Ah, I see. I typically think that Z should be I-S direction. But this program really just takes the last dimension in data as Z.