3dAllineate Fatal Error

AFNI Message Board
1

Hello,

I am getting a fatal error when preprocessing a functional run for single subject with a script generated via afni proc.

This is the error in the output:
[7m** FATAL ERROR:e[0m 3dAllineate fails :: base image has 0 nonzero voxels (< 100)

and it looks like it is occurring at this point in the script:
3dAllineate -base mprage_ns+tlrc
-input vr_base+orig
-1Dmatrix_apply mat.basewarp.aff12.1D
-mast_dxyz 2.5
-prefix final_epi_vr_base

I have preprocessed another run from this subject with the same script and did not receive this error.

Do you have any thoughts on this?

Thanks!

2

That is a bit strange. What does 3dinfo say about that dataset?

3dinfo vr_base+orig

And how about:

3dinfo mprage_ns+tlrc | grep extent

  • rick
3

Thanks for response.

Output from 3dinfo vr_base+orig:

[dburr@hera A000583.ulab.noblur.results] > 3dinfo vr_base+orig
++ 3dinfo: AFNI version=AFNI_17.1.02 (Apr 27 2017) [64-bit]

Dataset File: vr_base+orig
Identifier Code: AFN_WsPW3RdE6DChu8s_nV2J8g Creation Date: Sun Jun 11 15:22:45 2017
Template Space: ORIG
Dataset Type: Anat Bucket (-abuc)
Byte Order: LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode: BRIK
Storage Space: 995,328 (995 thousand [kilo]) bytes
Geometry String: “MATRIX(2.463886,-0.414966,0.084067,-99.21497,0.411917,2.464162,0.090726,-152.299,-0.097921,-0.075564,2.496938,-14.74457):96,96,54”
Data Axes Tilt: Oblique (9.751 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: 52.348 [L] -to- 289.848 [L] -step- 2.500 mm [ 96 voxels]
A-to-P extent: -278.661 [A] -to- -41.161 [A] -step- 2.500 mm [ 96 voxels]
I-to-S extent: -23.072 [I] -to- 109.428 [S] -step- 2.500 mm [ 54 voxels]
Number of values stored at each pixel = 1
– At sub-brick #0 ‘#2’ datum type is short: 0 to 1338

Output from 3dinfo mprage_ns+tlrc | grep extent:

[dburr@hera A000583.ulab.noblur.results] > 3dinfo mprage_ns+tlrc | grep extent
++ 3dinfo: AFNI version=AFNI_17.1.02 (Apr 27 2017) [64-bit]
R-to-L extent: -96.000 [R] -to- 96.000 [L] -step- 1.000 mm [193 voxels]
A-to-P extent: -96.000 [A] -to- 132.000 [P] -step- 1.000 mm [229 voxels]
I-to-S extent: -78.000 [I] -to- 114.000 [S] -step- 1.000 mm [193 voxels]
[dburr@hera A000583.ulab.noblur.results] >

Also it may be worth noting that this was the only subject to require ginormous_move

Thanks!

4

That vr_base+orig dataset is far off from having a center
anywhere near 0,0,0. Note the extents:

R-to-L extent: 52.348 [L] -to- 289.848 [L] -step- 2.500 mm [ 96 voxels]
A-to-P extent: -278.661 [A] -to- -41.161 [A] -step- 2.500 mm [ 96 voxels]
I-to-S extent: -23.072 -to- 109.428 [S] -step- 2.500 mm [ 54 voxels]

It is all left and all anterior. It seems that some piece of
software must have thrown its coordinates away, or
simply messed them up. That data almost assuredly did
not some directly from a scanner. What happened to it
before it was given to afni_proc.py?

The -ginormous_move option is not going to fix this.
You might be better off running @Align_Centers on
it (e.g. -base TT_N27+tlrc) before using afni_proc.py.

  • rick
5

thanks! I am running with Align_Centers now…thanks!
Before afni_proc, the only thing done was dicom conversion with:
Dimon -infile_prefix 000 -dicom_org -gert_create_dataset

6

It would be very strange for the DICOM files to
show the data so far off from 0,0,0. Do you know
of some reason why the subject might not have
been centered in the scanner?

In any case, @Align_Centers should help.

  • rick