afni_proc.py WARNING - assuming TR=1.0

MeganQ · January 13, 2022, 4:34pm

Hello all,

I am running afni_proc.py and get the following warnings when running:

*+ WARNING: Input dataset is not 3D+time; assuming TR=1.0

set ovals = ( `1d_tool.py -set_run_lengths $tr_counts

                      -index_to_run_tr $minindex` )

*+ WARNING: some value in tpattern is outside range 0…TR=1.75

My TR is in fact 1.75 seconds, here is the 3info from my run01+orig.HEAD file which I’m using as my input dataset. Any ideas why it is assuming a TR of 1 when it states TR = 1.75? And why it’s stating that this file is not 3D+time?

++ 3dinfo: AFNI version=AFNI_20.3.03 (Dec 7 2020) [64-bit]

Dataset File: run1+orig
Identifier Code: XYZ_j27bciN4LXvm_6SHyUj-lQ Creation Date: Wed Jan 12 15:37:28 2022
Template Space: ORIG
Dataset Type: Echo Planar (-epan)
Byte Order: LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode: BRIK
Storage Space: 222,310,400 (222 million) bytes
Geometry String: “MATRIX(3,0,0,-115.7627,0,-2.95351,0.5261,105.8149,0,0.5261,2.95351,-105.2367):80,80,52”
Data Axes Tilt: Oblique (10.100 deg. from plumb)
Data Axes Approximate Orientation:
first (x) = Right-to-Left
second (y) = Posterior-to-Anterior
third (z) = Inferior-to-Superior [-orient RPI]
R-to-L extent: -115.763 [R] -to- 121.237 [L] -step- 3.000 mm [ 80 voxels]
A-to-P extent: -131.185 [A] -to- 105.815 [P] -step- 3.000 mm [ 80 voxels]
I-to-S extent: -105.237 [I] -to- 47.763 [S] -step- 3.000 mm [ 52 voxels]
Number of time steps = 167 Time step = 1.75000s Origin = 0.00000s Number time-offset slices = 52 Thickness = 3.000
– At sub-brick #0 ‘#0’ datum type is float: 0 to 29398
– At sub-brick #1 ‘#1’ datum type is float: 0 to 30062
– At sub-brick #2 ‘#2’ datum type is float: 0 to 32440
** For info on all 167 sub-bricks, use ‘3dinfo -verb’ **

----- HISTORY -----
[tue50988@cla19097: Wed Jan 12 15:37:28 2022] {AFNI_20.3.03:linux_ubuntu_16_64} 3dcopy 20220109_102116funcacqcmrrMB2taskseatrun01s008a001.nii.gz run1

Thank you!!

rickr · January 13, 2022, 5:00pm

Hello,

That looks like a warning from 3dTshift. What is the output of:

3dinfo -slice_timing run1+orig

Thanks,

rick

MeganQ · January 13, 2022, 5:32pm

Thank you!

Here is the requested output.

tue50988@cla19097:/data/projects/STUDIES/SEAT/fMRI/afni/RawImagingData/s1562$ 3dinfo -slice_timing run1+orig
1060.791992|0.000000|1101.590942|40.799671|1142.390991|81.599350|1183.191040|122.399002|1223.989990|163.198700|1264.790039|203.998398|1305.589966|244.798096|1346.389038|285.597687|1387.188965|326.397400|1427.989014|367.197113|1468.787964|407.996796|1509.588013|448.796509|1550.387939|489.596191|1591.187988|530.395813|1631.987061|571.195496|1672.786987|611.995178|1713.587036|652.794922|1754.385986|693.594482|1795.186035|734.394226|1835.985962|775.193909|1876.785034|815.993591|1917.584961|856.793274|1958.385010|897.593018|1999.183960|938.392578|2039.984009|979.192322|2080.783936|1019.992004

rickr · January 13, 2022, 5:55pm

Those times seem to be in ms, yet they are being interpreted is being in s.

If that is the case, they could be scaled by 0.001 via something like this
(breaking it up for clarity):

3dinfo -slice_timing -sb_delim ' ' run1+orig > slice_timing.txt
3drefit -Tslices '*0.001' `cat slice_timing.txt` run1+orig

That might then affect how you create the datasets, to be sure the correct unit is applied.

Please feel free to post what you do for that.

rick

MeganQ · January 13, 2022, 9:20pm

Thank you so much!

Taking one of the values (1060.791992) and translating it to seconds (which would be 1.060791992) requires * 0.001. So after running that command to do that to all timing slices, I get the following warnings.

Thank you again for your help on this! I’ve been so perplexed and stuck.

tue50988@cla19097:/data/projects/STUDIES/SEAT/fMRI/afni/RawImagingData/s1562$ 3drefit -Tslices ‘*0.001’ cat slice_timing.txt run1+orig
++ 3drefit: AFNI version=AFNI_20.3.03 (Dec 7 2020) [64-bit]
++ Authored by: RW Cox
++ Processing AFNI dataset run1+orig
*+ WARNING: -Tslices: altering existing slice offsets!
*+ WARNING: -Tslices value 1.75439 (#35) is greater than TR=1.75
*+ WARNING: -Tslices value 1.79519 (#37) is greater than TR=1.75
*+ WARNING: -Tslices value 1.83599 (#39) is greater than TR=1.75
*+ WARNING: -Tslices value 1.87679 (#41) is greater than TR=1.75
*+ WARNING: -Tslices value 1.91759 (#43) is greater than TR=1.75
*+ WARNING: -Tslices value 1.95839 (#45) is greater than TR=1.75
*+ WARNING: -Tslices value 1.99918 (#47) is greater than TR=1.75
*+ WARNING: -Tslices value 2.03998 (#49) is greater than TR=1.75
*+ WARNING: -Tslices value 2.08078 (#51) is greater than TR=1.75
++ 3drefit processed 1 datasets

rickr · January 13, 2022, 11:32pm

Indeed. Looking at the 3dinfo -slice_timing output from the prior message, the times go up to 2080.783936.

So while they do look like millisecond times, they do not match a 1.75s TR.
In fact, they do not match any “round” TR. Assuming they partition a TR evenly, the smallest (non-zero) time plus the largest time should equal the TR.
In this case that would be:

2121.583607 = 2080.783936 + 40.799671

That is a strange number for a TR. Notably, 40.799671 does not evenly divide almost any somewhat round TR.
But one somewhat close case is that 40.799671 miiiight be appropriate for TR=2s and 49 slices, for what it’s worth.

Anyway, you should revisit exactly where that information came from. It does not seem correct.
Is there any prior information that you can provide?

The fact that the voxels are isotropic is suspicious, too. Are you sure it wasn’t resampled onto this grid?

rick

MeganQ · January 14, 2022, 2:09pm

Hi Rick,

Thank you so much for this! I’m going to look into that slice timing. Notably, the slice timing shown when I do 3dinfo is different than the slice timing that is listed in my .json file when I convert my dicoms into bids format. So it seems like something must have gone wrong in the conversion into nifti then the BRIK and HEAD files.

rickr · January 14, 2022, 3:17pm

Maybe the creators of those NIFTI files have old timing in the NIFTI extensions that does not match what is in the json files. You can use 3dfefit to correct the timing based on the JSON.

But it would be good to verify this with the NIFTI files.

Assuming you have some EPI_ORIG.nii.gz dataset, what is the output of:

nifti_tool -disp_exts -infiles EPI_ORIG.nii.gz | grep -A 10 -B 5 TAXIS_OFFSETS

Thanks,

rick

MeganQ · January 20, 2022, 2:58pm

Hi Rick,

I have a few more bits of information for you that will hopefully help! First, I re-created the nifti files using dcm2nii in hopes that this might get rid of the timing issue. I still get the same error, but here are things I’ve tried and looked at:

When I run the nifti_tool command you suggested I get the following:

tue50988@cla19097:/data/projects/STUDIES/SEAT/fMRI/afni/RawImagingData/s1562$ nifti_tool -disp_exts -infiles sub-s1562_task-seat_run-01_bold.nii.gz | grep -A 10 -B 5 TAXIS_OFFSETS
tue50988@cla19097:/data/projects/STUDIES/SEAT/fMRI/afni/RawImagingData/s1562$ nifti_tool -disp_exts -infiles sub-s1562_task-seat_run-01_bold.nii.gz
header file ‘sub-s1562_task-seat_run-01_bold.nii.gz’, num_ext = 0

When I re-run 3dinfo -slice_timing on that nifti I get this:

tue50988@cla19097:/data/projects/STUDIES/SEAT/fMRI/afni/RawImagingData/s1562$ 3dinfo -slice_timing sub-s1562_task-seat_run-01_bold.nii.gz
** AFNI converts NIFTI_datatype=512 (UINT16) in file /data/projects/STUDIES/SEAT/fMRI/afni/RawImagingData/s1562/sub-s1562_task-seat_run-01_bold.nii.gz to FLOAT32
Warnings of this type will be muted for this session.
Set AFNI_NIFTI_TYPE_WARN to YES to see them all, NO to see none.
0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000

I looked at all the files from pb00 to pb05 to see if they have the correct TR and measurements (e.g., number of TRs) and they do:

tue50988@cla19097:/data/projects/STUDIES/SEAT/fMRI/afni/IndvlLvlAnalyses/s1562/s1562.results.ClpsRspns_NL.1mm$ 3dinfo pb05.s1562.r01.scale+tlrc.BRIK.gz
++ 3dinfo: AFNI version=AFNI_20.3.03 (Dec 7 2020) [64-bit]

Dataset File: pb05.s1562.r01.scale+tlrc
Identifier Code: XYZ_IBjQY9dvJa_3K1NmRCMpBw Creation Date: Mon Jan 17 11:45:01 2022
Template Space: TT_N27
Dataset Type: Echo Planar (-epan)
Byte Order: LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode: BRIK
Storage Space: 115,430,400 (115 million) bytes
Geometry String: “MATRIX(3,0,0,-79.5,0,3,0,-79.5,0,0,3,-63.5):54,64,50”
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.500 [R] -to- 79.500 [L] -step- 3.000 mm [ 54 voxels]
A-to-P extent: -79.500 [A] -to- 109.500 [P] -step- 3.000 mm [ 64 voxels]
I-to-S extent: -63.500 [I] -to- 83.500 [S] -step- 3.000 mm [ 50 voxels]
Number of time steps = 167 Time step = 1.75000s Origin = 0.00000s
– At sub-brick #0 ‘sub-s1562_task-s[0]’ datum type is float: 0 to 129.629
– At sub-brick #1 ‘sub-s1562_task-s[1]’ datum type is float: 0 to 136.11
– At sub-brick #2 ‘sub-s1562_task-s[2]’ datum type is float: 0 to 123.041
** For info on all 167 sub-bricks, use ‘3dinfo -verb’ **

I also looked at the 1D output files to see if they have the correct number of TRs and they do:

tue50988@cla19097:/data/projects/STUDIES/SEAT/fMRI/afni/IndvlLvlAnalyses/s1562/s1562.results.ClpsRspns_NL.1mm$ cat outcount.r01.1D | wc
167 167 1336

Looking at the script output, this appears to be where things are throwing a warning.

cat outcount.r01.1D outcount.r02.1D outcount.r03.1D
cat rm.out.cen.r01.1D rm.out.cen.r02.1D rm.out.cen.r03.1D
set minindex = 3dTstat -argmin -prefix - outcount_rall.1D\'
3dTstat -argmin -prefix - outcount_rall.1D’
++ 3dTstat: AFNI version=AFNI_20.3.03 (Dec 7 2020) [64-bit]
++ Authored by: KR Hammett & RW Cox
e[7m*+ WARNING:e[0m Input dataset is not 3D+time; assuming TR=1.0
set ovals = ( 1d_tool.py -set_run_lengths $tr_counts -index_to_run_tr $minindex )
1d_tool.py -set_run_lengths 167 167 167 -index_to_run_tr 83

Given that we’ve confirmed that the input and output all specify a TR of 1.75, we’re stumped! Is it possible that this is a benign warning that’s not actually happening with these data?

Again I greatly greatly appreciate all your help on this!!!

rickr · January 20, 2022, 4:39pm

It looks like the original data has no slice timing in it. However, if created by dcm2niix, there is probably a JSON side car with the timing information.

Since the BOLD file has name sub-s1562_task-seat_run-01_bold.nii.gz,
look for a corresponding file named sub-s1562_task-seat_run-01_bold.json
(or similar).

If that exists, does it seem to have timing information? There should be an entry called “SliceTIming”.

rick

MeganQ · January 20, 2022, 5:11pm

Hi Rick,

There is absolutely an a json file to go with that! Here’s the slice timing information

“SliceTiming”: [0, 1.2625, 0.7975, 0.3325, 1.595, 1.13, 0.665, 0.2, 1.4625, 0.9975, 0.5325, 0.065, 1.33, 0.865, 0.3975, 1.6625, 1.1975, 0.73, 0.265, 1.53, 1.065, 0.5975, 0.1325, 1.3975, 0.93, 0.465, 0, 1.2625, 0.7975, 0.3325, 1.595, 1.13, 0.665, 0.2, 1.4625, 0.9975, 0.5325, 0.065, 1.33, 0.865, 0.3975, 1.6625, 1.1975, 0.73, 0.265, 1.53, 1.065, 0.5975, 0.1325, 1.3975, 0.93, 0.465],

rickr · January 20, 2022, 7:29pm

Those look like appropriate slice times.

They could be applied with “3drefit -Tslices”, for example, or even with 3dTcat (to make a copy) using the to3d-style -tpattern option.

It sort of begs the question of where the bad times came from. But at least these seem like what you can work with.

rick

MeganQ · January 20, 2022, 8:50pm

Thank you! And yes I agree, it must have somehow gotten corrupted or changed during one of the initial conversions. But it looks good when I use this original nii file. I’ll apply those and re-run!