Hi,

Just to add to this - it is quite common that the TR you _request_ cannot be met _exactly_ due to various constraints on the physics of the acquisition. The 0.5% change that you have here looks like it is due to this and that it was the best approximation that the scanner/operator could achieve. To be sure you should check the original images (e.g. Dicom files) and/or talk to the operator.

All the best,
Mark


Matthew Webster <[log in to unmask]> wrote:
Hi David,
I'm surprised that this gives a TR of 2.5099999905 in the GUI - when I load in a file with a TR of 2.5125000477 locally, that is the value that appears in the TR box. Either way these are fields that are set from the scanner information when the NIFTI file is first created- so I suspect that the exact scanning TR was not exactly 2.5s. You can manually set the TR to 2.5 in the GUI after loading the 4D data, however it would be best to check with the scanner operator what the actual scanning parameters were.

Kind Regards

Matthew

sure the output of fslinfo is
data_type      INT16
dim1           64
dim2           64
dim3           29
dim4           287
datatype       4
pixdim1        3.2031250000
pixdim2        3.2031250000
pixdim3        3.1999664307
pixdim4        2.5125000477
cal_max        0.0000
cal_min        0.0000
file_type      NIFTI-1+

Cheers