TR differs in nifti and header (and other info)

AFNI Message Board
1

This conversation changed topic from this thread:
https://afni.nimh.nih.gov/afni/community/board/read.php?1,169036,169044#msg-169044
… focusing on TRs instead of alignment.

Hi, Philipp-

I edited my previous reply in the thread with more info.

I am not sure about the previous issues, but hopefully this will clear things up for current/further processing.

RE. the TR warnings: the ones you refer to appearing during processing are likely ignorable, and probably happening during some internal concatenation procedure where it isn’t a problem. Do you have other specific TR considerations?

-pt

2

The TR of the functional runs is 2.27 s. The raw .nii files display a TR of 1 s when inspecting them with 3dinfo.

If I simply preprocess these raw functional runs with AFNI proc, the AFNI proc HTML QC page still displays a TR of 1 s.
Hence, I changed the TR from 1 to 2.27 s using 3drefit. The 3drefit output functional runs are now forwarded to AFNI proc with the settings you suggested.

So right now there are no more questions and thanks for the detailled update in your previous answer.

3

Hi, Philipp-

That is odd. Can you check the NIFTI header directly, with:


nifti_tool -disp_hdr -field pixdim -infiles DSET_EPI

Does that show a TR of 1s? That is, is the value of pixdim[4] (zerobased counting) equal to 1.0? Note that first 5 pixdim values are:
pixdim[0] → flag about qform or sform
pixdim[1-3] → spatial voxel dims
pixdim[4] → TR

It is possible that there is a conflict between a stored extension (with 3dinfo would check) and the primary NIFTI header (which nifti_tool will check). So, please let us know about that, and then we can decide best how to address that issue.

–pt

4

This is the output of the code that you provided for the raw functional scan:


N-1 header file 'task-eoec_bold.nii.gz', num_fields = 1
  name                offset  nvals  values
  ------------------- ------  -----  ------
  pixdim                76      8    -1.0 3.203125 3.203125 3.2 0.0 0.0 0.0 0.0

And this is the output of 3dinfo for the exact same file:


Identifier Code: NII_gdAWnoolfeS8ElHNF-3QOA  Creation Date: Tue Dec 13 16:27:35 2022
Template Space:  ORIG
Dataset Type:    Echo Planar (-epan)
Byte Order:      LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode:    NIFTI
Storage Space:   179,806,208 (180 million) bytes
Geometry String: "MATRIX(3.203125,-3.20312e-16,2.182395e-16,-101.9189,-3.20312e-16,-2.342617,2.182395,25.05877,0,2.184526,2.340332,-116.7211):64,64,47"
Data Axes Tilt:  Oblique (43.000 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:  -101.919 [R] -to-    99.878 [L] -step-     3.203 mm [ 64 voxels]
A-to-P extent:  -176.738 [A] -to-    25.059 [P] -step-     3.203 mm [ 64 voxels]
I-to-S extent:  -116.721 [I] -to-    30.479 [S] -step-     3.200 mm [ 47 voxels]
Number of time steps = 467  Time step = 1.00000s  Origin = 0.00000s
  -- At sub-brick #0 '?' datum type is short
  -- At sub-brick #1 '?' datum type is short
  -- At sub-brick #2 '?' datum type is short
** For info on all 467 sub-bricks, use '3dinfo -verb' **
5

So the TR is not even in the NIFTI dataset? Is TR specified in an accompanying JSON sidecar?

  • rick
6

I don’t have additional files, no. Is it an option to define the TR as I did with 3drefit, or do I run into problems doing this?

7

Using 3drefit is a fine way to go, that or a related solution, like nifti_tool.

It might be good to revisit where these came from though, to get the TR set properly from the start. You would not want to require remembering to set that with all of the data coming in, it should already be in the NIFTI files.

Do you know how these datasets were created?

  • rick