I’m trying to save a HEAD/BRIK file to nii for further processing outside of AFNI. But when I run this command:
3dAFNItoNIFTI -prefix ${subj}.REML_IMs_reord.nii.gz ${subj}.REML_IMs_reord+tlrc
I get this error message:
++ 3dAFNItoNIFTI: AFNI version=AFNI_21.3.17 (Dec 30 2021) [64-bit]
** ERROR: nifti_image_write_hdr_img: NBL does not match nim
I’ve tried running 3dAFNItoNIFTI with -pure and -denote, but no dice.
An old thread from this message board from November 18, 2014 08:28PM reported a similar error message, where Rick suggested “removing the NIFTI extensions from the dastaset”. I don’t know how to do that when starting with an AFNI file, or if it’s even relevant.
I’d appreciate any advice, even if it’s just to let me know what additional info I need to provide to help diagnose the issue.
Thank you, Rick. This is getting more interesting. 3dcopy give the same error I got before:
3dcopy ${subj}.REML_IMs_reord+tlrc copy_reord.nii.gz
++ 3dcopy: AFNI version=AFNI_21.3.17 (Dec 30 2021) [64-bit]
** ERROR: nifti_image_write_hdr_img: NBL does not match nim
I forgot to say that in these cases a NIFTI file is actually produced. However, when I run 3dinfo on it, this is what happens:
3dinfo copy_reord.nii.gz
++ 3dinfo: AFNI version=AFNI_21.3.17 (Dec 30 2021) [64-bit]
** ERROR (nifti_image_read): short header read ‘/home/wgraves/data/bsafAG/data/mcwRA/copy_reord.nii.gz’
** FATAL ERROR: Can’t open dataset copy_reord.nii.gz
** Program compile date = Dec 30 2021
But the 3dbucket command actually does work to successfully save it as a NIFTI file. Here’s the output of 3dinfo on that resulting file:
3dinfo bucket_reord.nii.gz
++ 3dinfo: AFNI version=AFNI_21.3.17 (Dec 30 2021) [64-bit]
Dataset File: /home/wgraves/data/bsafAG/data/mcwRA/bucket_reord.nii.gz
Identifier Code: XYZ_IsUKqzK2tsZ7jPpyjmPHvw Creation Date: Wed Jan 5 17:31:16 2022
Template Space: TT_N27
Dataset Type: Anat Bucket (-abuc)
Byte Order: LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode: NIFTI
Storage Space: 1,060,200,000 (1.1 billion) bytes
Geometry String: “MATRIX(2,0,0,-79,0,2,0,-79,0,0,2,-64):80,95,75”
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: -79.000 [R] -to- 79.000 [L] -step- 2.000 mm [ 80 voxels]
A-to-P extent: -79.000 [A] -to- 109.000 [P] -step- 2.000 mm [ 95 voxels]
I-to-S extent: -64.000 [I] -to- 84.000 [S] -step- 2.000 mm [ 75 voxels]
Number of values stored at each pixel = 465
– At sub-brick #0 ‘allwords#36_Tstat’ datum type is float: -8.46264 to 8.56861
statcode = fitt; statpar = 673
– At sub-brick #1 ‘allwords#400_Tstat’ datum type is float: -4.15827 to 4.30151
statcode = fitt; statpar = 673
– At sub-brick #2 ‘allwords#408_Tstat’ datum type is float: -4.11308 to 5.13197
statcode = fitt; statpar = 673
** For info on all 465 sub-bricks, use ‘3dinfo -verb’ **
Indeed, it would be nice to understand what is happening.
Is there any chance that you could mail me the actual ${subj}.REML_IMs_reord+tlrc.HEAD file? (click on my name for the address)
If I could replicate the issue, it would be much easier to figure out.
That’s right, Rick. It was all processed within AFNI, using the programs you listed. I did notice what I thought was a mis-specified time field, but I wasn’t sure if that was what was causing this issue with converting to NIFTI, or how to fix it. My intuition is that the 3dbucket step when I re-order the sub-briks across subjects to all be in the same order is what created the problem.
In case it’s not clear from the history in the header, here’s the command I used for that:
3dbucket -fbuc -prefix ${subj}.REML_IMs_reord ${subj}.REML_IMs+orig’[1dcat reorder.1D]’
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.