problem saving HEAD/BRIK to nii

Dear AFNI Experts,

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.

Best,
Will

Hi Will,

That is peculiar. Note that almost any AFNI command should be able to write as NIFTI (though presumably others would fail similarly).

Just to be sure, do you get similar failures with these commands?

3dcopy ${subj}.REML_IMs_reord+tlrc copy_reord.nii.gz
3dbucket -prefix bucket_reord.nii.gz ${subj}.REML_IMs_reord+tlrc

Would it be possible to see the “3dinfo” output on that? You could send it via PM if that is preferable.

Thanks,

  • rick

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’ **

----- HISTORY -----
[wgraves@argus: Wed Oct 13 00:43:56 2021] Matrix source: ; 3dDeconvolve -input 3Dout.words1+orig 3Dout.words2+orig 3Dout.words3+orig 3Dout.words4+orig 3Dout.words5+orig -mask epimask+orig -x1D R.xmat.1D -x1D_stop -polort A -censor Mcensor.1D -CENSORTR ‘*:0-5’ -num_stimts 8 -stim_file 1 ‘MP.all.1D[1]’ -stim_label 1 MP1 -stim_base 1 -stim_file 2 ‘MP.all.1D[2]’ -stim_label 2 MP2 -stim_base 2 -stim_file 3 ‘MP.all.1D[3]’ -stim_label 3 MP3 -stim_base 3 -stim_file 4 ‘MP.all.1D[4]’ -stim_label 4 MP4 -stim_base 4 -stim_file 5 ‘MP.all.1D[5]’ -stim_label 5 MP5 -stim_base 5 -stim_file 6 ‘MP.all.1D[6]’ -stim_label 6 MP6 -stim_base 6 -stim_file 7 ./noise.1D -stim_label 7 noise -stim_base 7 -local_times -stim_times_IM 8 ./regressors/lsstimes.01.1D ‘BLOCK(1,1)’ -stim_label 8 allwords
[wgraves@argus: Wed Oct 13 00:43:56 2021] {AFNI_21.1.20:linux_ubuntu_16_64} 3dREMLfit -matrix R.xmat.1D -input ‘3Dout.words1+orig 3Dout.words2+orig 3Dout.words3+orig 3Dout.words4+orig 3Dout.words5+orig’ -mask epimask+orig -tout -nobout -Rbuck 2426.REML_IMs -verb
[wgraves@argus: Wed Jan 5 16:35:24 2022] {AFNI_21.3.17:linux_ubuntu_16_64} 3dbucket -fbuc -prefix 2426.REML_IMs_reord.nii.gz ‘2426.REML_IMs+orig[1dcat reorder.1D]’
[wgraves@hermes: Wed Jan 5 16:38:29 2022] {AFNI_21.3.17:linux_ubuntu_16_64} 3dNwarpApply -nwarp MPRAGE_sag_al_qw_WARP+tlrc -source 2426.REML_IMs_reord.nii.gz -master /usr/lib/afni/bin/TT_N27_SSW.nii.gz -dxyz 2 -prefix /home/wgraves/data/bsafAG/data/mcwRA/2426.REML_IMs_reord+tlrc
[wgraves@hermes: Wed Jan 5 17:31:16 2022] {AFNI_21.3.17:linux_ubuntu_16_64} 3dbucket -prefix bucket_reord.nii.gz 2426.REML_IMs_reord+tlrc

So I guess I’ll just stick with your 3dbucket trick (thanks for that!). But it would be nice to know what’s going on here.

Best,
Will

Hi Will,

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.

Thanks,

  • rick

Thanks a lot for that Will. There is a time axis field that does not match the number of volumes that is otherwise stored.

Was the dataset created only by AFNI programs? It seems to have a history of:

3dDeconvolve
3dREMLfit
3dbucket
3dNwarpApply

Did anything else modify this?

Thanks,

  • rick

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]’

I tested a case with 3dbucket and a reorder.1D file, but it worked correctly.
I will look into this more.

Thanks,

  • rick

Thanks for letting me know, Rick. I’d be happy to send you the 1D file I used for reordering if that would help you break it the way I apparently did!

Best,
Will

Sure, having the 1D file would be nice, thanks!

  • rick