NIFTI to BRIK problem

AFNI Message Board
1

Hi,
I am trying to convert epi NIFTI files to BRIK format, but am having problems. When I do 3dinfo on the NIFTI files, it says that they are in orig space. When I use 3dcopy to convert to BRIK (3dcopy inset prefix) the output is in tlrc space. When I try to use 3drefit to change the view back to orig, the image moves dramatically and no longer aligns with my anatomical. Is there a reason why afni may want to convert NIFTI files to tlrc space? Or why they would move drastically in space when I try to change the view back to orig?

This is creating fatal errors when I try to run afni_proc, so I would be grateful for any help!

2

If this helps, here is the output of 3dinfo for the NIFTI file and for the 3dcopied file in orig space (the one that is grossly misaligned)
[gowinjl@biowulf 3537997]$ 3dinfo nv_3537997_20141103_resting_state.nii
++ 3dinfo: AFNI version=AFNI_17.2.10 (Aug 30 2017) [64-bit]

Dataset File: nv_3537997_20141103_resting_state.nii
Identifier Code: XYZ_Kjr2NHWk-5QN8JmicU5DOw Creation Date: Fri Nov 21 09:39:47 2014
Template Space: ORIG
Dataset Type: Echo Planar (-epan)
Byte Order: LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode: NIFTI
Storage Space: 88,473,600 (88 million [mega]) bytes
Geometry String: “MATRIX(3.75,0,0,-123.5351,0,-3.75,0,113.4413,0,0,3.8,-62.14165):64,64,36”
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Right-to-Left
second (y) = Posterior-to-Anterior
third (z) = Inferior-to-Superior [-orient RPI]
R-to-L extent: -121.574 [R] -to- 114.676 [L] -step- 3.750 mm [ 64 voxels]
A-to-P extent: -122.188 [A] -to- 114.062 [P] -step- 3.750 mm [ 64 voxels]
I-to-S extent: 42.776 [S] -to- 175.776 [S] -step- 3.800 mm [ 36 voxels]
Number of time steps = 300 Time step = 2.00000s Origin = 0.00000s
– At sub-brick #0 ‘#0’ datum type is short: 0 to 1852
– At sub-brick #1 ‘#1’ datum type is short: 0 to 1841
– At sub-brick #2 ‘#2’ datum type is short: 0 to 1842

[gowinjl@biowulf 3537997]$ 3dinfo nv_3537997_20141103_resting_state+orig
++ 3dinfo: AFNI version=AFNI_17.2.10 (Aug 30 2017) [64-bit]

Dataset File: nv_3537997_20141103_resting_state+orig
Identifier Code: XYZ_my3aiyHAetEXqswNwVN35w Creation Date: Thu Aug 31 19:33:26 2017
Template Space: ORIG
Dataset Type: Echo Planar (-epan)
Byte Order: LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode: BRIK
Storage Space: 88,473,600 (88 million [mega]) bytes
Geometry String: “MATRIX(3.75,0,0,-121.5737,0,-3.75,0,114.0624,0,0,3.8,42.77607):64,64,36”
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Right-to-Left
second (y) = Posterior-to-Anterior
third (z) = Inferior-to-Superior [-orient RPI]
R-to-L extent: -121.574 [R] -to- 114.676 [L] -step- 3.750 mm [ 64 voxels]
A-to-P extent: -122.188 [A] -to- 114.062 [P] -step- 3.750 mm [ 64 voxels]
I-to-S extent: 42.776 [S] -to- 175.776 [S] -step- 3.800 mm [ 36 voxels]
Number of time steps = 300 Time step = 2.00000s Origin = 0.00000s
– At sub-brick #0 ‘#0’ datum type is short: 0 to 1852
– At sub-brick #1 ‘#1’ datum type is short: 0 to 1841
– At sub-brick #2 ‘#2’ datum type is short: 0 to 1842

3

Hi-

What is the output of:


3dinfo -av_space  -space -prefix FILE

on each of the files?

–pt

4

[gowinjl@biowulf 3537997]$ 3dinfo -av_space -space -prefix nv_3537997_20141103_resting_state.nii
+tlrc ORIG nv_3537997_20141103_resting_state.nii
[gowinjl@biowulf 3537997]$ 3dinfo -av_space -space -prefix nv_3537997_20141103_resting_state+orig
+orig ORIG nv_3537997_20141103_resting_state

I see that the NIFTI file has +tlrc. What should I do about that?

5

Would you please provide the output from:

nifti_tool -disp_hdr -infile nv_3537997_20141103_resting_state.nii

Thanks,

  • rick
6

num_fields = 43

all fields:
name offset nvals values

sizeof_hdr 0 1 348
data_type 4 10
db_name 14 18
extents 32 1 0
session_error 36 1 0
regular 38 1 r
dim_info 39 1 48
dim 40 8 4 64 64 36 300 1 1 1
intent_p1 56 1 0.0
intent_p2 60 1 0.0
intent_p3 64 1 0.0
intent_code 68 1 0
datatype 70 1 4
bitpix 72 1 16
slice_start 74 1 0
pixdim 76 8 -1.0 3.75 3.75 3.8 2.0 0.0 0.0 0.0
vox_offset 108 1 9856.0
scl_slope 112 1 1.0
scl_inter 116 1 0.0
slice_end 120 1 35
slice_code 122 1 0
xyzt_units 123 1 10
cal_max 124 1 0.0
cal_min 128 1 0.0
slice_duration 132 1 0.0
toffset 136 1 0.0
glmax 140 1 0
glmin 144 1 0
descrip 148 80
aux_file 228 24
qform_code 252 1 1
sform_code 254 1 2
quatern_b 256 1 -0.0
quatern_c 260 1 1.0
quatern_d 264 1 0.0
qoffset_x 268 1 127.602898
qoffset_y 272 1 -115.184601
qoffset_z 276 1 -65.628326
srow_x 280 4 -3.748942 -0.007334 -0.089933 119.408295
srow_y 296 4 -0.044252 3.396592 1.609798 -146.960602
srow_z 312 4 -0.077279 -1.589215 3.440997 4.771574
intent_name 328 16
magic 344 4 n+1

7

That looks like 2 different transformations, depending on
how obliquity affects it. Certainly the qform_code is
different from the sform_code, which is uncommon.

Would you also show the actual transformation matrices?

nifti_tool -disp_nim -infile nv_3537997_20141103_resting_state.nii | grep to_xyz

What software created that dataset?

In any case, you could try applying AFNI_NIFTI_VIEW
when making a copy:

3dcopy -DAFNI_NIFTI_VIEW=orig nv_3537997_20141103_resting_state.nii NEW_DSET

Thanks,

  • rick
8

Hi Rick,
Here’s the matrix you requested:
qto_xyz 400 16 -3.75 -0.0 -0.0 123.535103 0.0 3.75 -0.0 -113.441299 -0.0 0.0 3.8 -62.141651 0.0 0.0 0.0 1.0
sto_xyz 656 16 -3.737319 -0.086822 -0.29959 121.573715 -0.269864 2.658937 2.665612 -114.062431 -0.148725 -2.642918 2.691609 42.776073 0.0 0.0 0.0 1.0

The file was created by a transformation from a BRIK file to NIFTI using 3dresample:

3dresample -orient RPI -prefix …/nii/NV_3537997_20141103_resting_state.nii -inset RestingState_eyes_open+orig.BRIK

Could that command have caused the problem with the file?