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