Discrepancy of repetition time between dicom and nifti header

Hi AFNI team,

I am using resting state data from a database. I noticed that for some of the participants the TRs in the dicom and nifti headers do not match. To pull this information I used the dicom_hdr command (‘ACQ Repetition Time’ field) and 3dinfo -tr. Do you know why this might occur? Should I change the information in the nifti header to match the dicom information?


Depending on the processing pipeline, TR information can be lost along the way. In AFNI, if the information is missing, it is usually considered to be 1.0 seconds by default. You can update it with “3drefit -TR n.nn mydset” using the n.nn seconds and dataset names in the command. The values you may see in the DICOM are not necessarily correct either, so you would have to know from your scan settings which, if either, to trust.

Hi Daniel,

Thanks for the information. I will update the TRs with 3drefit.

I am following proc.py example 11 for preprocessing. This is a basic question but how is the TR information used in preprocessing? For example, if the TR is wrongly coded as 6s instead of 3s in the NIFTI header, how would this affect the data that’s output from proc.py?

Thank you!

Hi Jenna,

In a task analysis, having an incorrect TR (esp by a factor of 2) would be severely destructive, as it would throw off all of the stimulus event times.

But in a resting state analysis, particularly a single-echo one using ROI regressors and no band passing and no retroicor, messing up the TR would not seem too terrible. Perhaps the biggest problem would be using a -polort that is much too high or low if the run duration is twice or half as long as it should be. For a fixed -polort, the entire regression matrix might be TR-independent. It depends on the exact command used.

But in any case, it is best to make sure. As Daniel said, it is hard to know what is correct. Usually, the DICOM files would be considered more reliable. But it begs the question of why they differ from the dataset. DICOM files are often anonymized these days, making them less reliable. And people constructing data packages make mistakes.

Is there any independent source of information on this?

Exactly what are the TRs in question here? And where does the data come from?

  • rick

Hi Rick,

Ok, thank you this is helpful. Below you will find my proc.py command. I modified example 11 to include bandpass filtering (0.01-0.1 Hz) in addition to motion and outlier censoring. Is it correct that while running the proc.py script the TR will be read from the EPI input (NIFTI) header? By including bandpassing in the pipeline with the wrong TR, I am affecting the DOF that are retained, correct?

afni_proc.py                                                                                                            \
                 -subj_id ${sid} -script proc.${sid} -scr_overwrite -out_dir ${sid}.results                      \
                 -blocks despike tshift align tlrc volreg blur mask scale                                               \
                     regress                                                                                                                   \
                 -radial_correlate_blocks tcat volreg                                                                           \
                 -copy_anat ${ss_dir}/anatSS.${sid}.nii                                                                       \
                 -anat_has_skull no                                                                                                     \
                 -anat_follower anat_w_skull anat  ${ss_dir}/anatU.${sid}.nii                                      \
                 -anat_follower_ROI aaseg anat ${fs_dir}/aparc.a2009s+aseg.nii.gz                         \
                 -anat_follower_ROI aeseg epi ${fs_dir}/aparc.a2009s+aseg.nii.gz                            \
                 -anat_follower_ROI FSvent epi ${fs_dir}/fs_ap_latvent.nii.gz                                     \
                 -anat_follower_ROI FSWe epi ${fs_dir}/fs_ap_wm.nii.gz                                           \
                 -anat_follower_erode FSvent FSWe                                                                           \
                 -dsets ${raw_epi}                                                                                                        \
                 -tcat_remove_first_trs 4                                                                                             \
                 -tshift_opts_ts -tpattern altplus						                                   \
                 -align_opts_aea -cost lpc+ZZ -giant_move -check_flip                                            \
                 -tlrc_base MNI152_2009_template_SSW.nii.gz                                                       \
                 -tlrc_NL_warp                                                                                                           \
                 -tlrc_NL_warped_dsets ${ss_dir}/anatQQ.${sid}.nii ${ss_dir}/anatQQ.${sid}.aff12.1D                     \
                     ${ss_dir}/anatQQ.${sid}_WARP.nii                                                                      \
                 -volreg_align_to MIN_OUTLIER                                                                              \
                 -volreg_align_e2a                                                                                                    \
                 -volreg_tlrc_warp                                                                                                     \
                 -blur_size 4                                                                                                              \
                 -mask_epi_anat yes                                                                                                \
                 -regress_motion_per_run                                                                                        \
                 -regress_ROI_PC FSvent 3                                                                                    \
                 -regress_ROI_PC_per_run FSvent                                                                         \
                 -regress_make_corr_vols aeseg FSvent                                                                 \
                 -regress_anaticor_fast                                                                                            \
                 -regress_anaticor_label FSWe                                                                               \
                 -regress_censor_motion 0.3										        \
 	      	 -regress_censor_outliers 0.1										        \
		 -regress_bandpass 0.01 0.1                                                                                  \
                 -regress_apply_mot_types demean deriv                                                              \
                 -regress_est_blur_epits                                                                                          \
                 -regress_est_blur_errts                                                                                          \
                 -html_review_style pythonic

I am using data from the ADNI database. In their help forum, they stated that values in the DICOM headers are checked for protocol compliance. In some instances, after converting to NIFTI, participants’ NIFTI/JSON files state that the TR is equal to 6s when the DICOM header states that the TR is equal to 3 seconds. Three seconds is more aligned with the protocol documents provided by ADNI. Should I update the TR information in the NIFTI header for these participants?


Hi Jenna,

The 6s TR seems too long (unless this is for an auditory study).
And while we don’t really recommend band passing, if you are going to do it, the TR should be correct.

We ran into a case (I think in ADNI, but am not positive) where the AFNI extension in the NIFTI header was made with a mistake, while the NIFTI header itself was okay. Maybe that applies here.

For one of the DSET.nii EPI datasets, what is the output of these 2 commands?

nifti_tool -disp_hdr -field pixdim -infiles DSET.nii
3dinfo -tr DSET.nii

If they disagree and the NIFTI header says 3s, then yes, go with that.

What do those commands show?

  • rick

Hi Rick,

Below are the outputs of each command:

nifti_tool -disp_hdr -field pixdim -infiles sub01.nii.gz
N-1 header file 'sub-002_S_0295_task-rest_run-01_bold.nii.gz', num_fields = 1
  name                offset  nvals  values
  ------------------- ------  -----  ------
  pixdim                76      8    -1.0 3.3125 3.3125 3.3125 6.021583 0.0 0.0 0.0

3dinfo -tr sub01.nii.gz

So, the TRs match between those two commands. However, when I grep the information from the dicom_hdr, it differs:

dicom_hdr $file | grep "Repetition Time"
ACQ Repetition Time//3000

The TR of 3000ms matches the protocol information for this participant. I’m not sure how or why it is getting changed in the conversion from dcm2niix. Should I change the TR information in the NIFTI header to match that of the dicom?


Chris Rorden suggested to figure out which version of dcm2niix was used. If it is not the latest stable version, you may want to update. If there is still a problem, post an issue on the dcm2niix Github page.


Also, I believe we have seen issues with missing/incorrect info in ADNI datasets a couple times before. I think coordinate and orientation information was missing in one previous case, but my memory is a little hazy, and I don’t have direct access to the data. There was this recent post on Neurostars saying where new issues can be directed.