Slice timing discrepancies between command output and visual inspection

,
1

Hello,

After converting my DICOMs to NIfTI, I ran the following command in AFNI to check the slice timing information:

3dinfo -slice_timing ./EPI.nii

The result was as follows:

0.945, 1.95, 0.8875, 1.89, 0.8275, 1.8325, … 0.12, 1.1225, 0.06, 1.065, 0, 1.005
(FYI, TR=2, # slices = 34, interleaved & descending)

However, using the AFNI GUI for images and graphs to manually examine the k coordinate (z-axis) and @t values, I found that the time-offsets per slice did not match the output of 3dinfo at all.

For example:

0, 0, 0.945, 0.945, 1.95, 0.885, 1.89, 0.8275… 1.3, 0.2375, 1.24, 0.1775, 1.1825, 0.1175, 1.1225, 0.06
(<–foot head–>, FYI)

It seems as if the bottom two slices were acquired at 0 seconds, followed by acquisition in descending order from the head.

It is possible that the output of the 3dinfo command can differ from the actual data?

2

Hello,

It is possible for timing to be messed up if for some reason it exists in an ext
ension and is then modified in the NIFTI header. What is the output from:

nifti_tool -disp_nim -field ext_list -infiles EPI.nii

Exactly how was this dataset created and possibly modified, do you know?

  • rick
3

Hello, Rick.
Thank you for your help!

The output is as follows:

header file ‘ACQ.nii’, num_fields = 1, fields:

name offset nvals values

ext_list 1128 1 ecode = 4, esize = 6384, edata = <?xml

This dataset is non-preprocessed EPI raw data (Siemens, 3T).
Please let me know if you need anything else.

ps. for your reference, outputs from other subject (who has normal slice timing) are as follows:

header file ‘CON02_ACQ.nii’, num_fields = 1, fields:

name offset nvals values

ext_list 1128 1 ecode = 4, esize = 6352, edata = <?xml

4

Okay, after running a test, I am more confused. These datasets do seem to have AFNI extensions in them, which could possibly differ from what is in the NIFTI headers (if one is either incorrect, or possibly not representable with a NIFTI slice_code). However, the timing in the AFNI extension seems to take priority with either 3dinfo or the GUI, which means they should match.

Just to be clear what is in there, what is the output from:

3dAttribute TAXIS_OFFSETS EPI.nii
nifti_tool -disp_hdr -field slice_code -infiles EPI.nii

And to be sure:

3dinfo -nk EPI.nii
3dAttribute TAXIS_OFFSETS EPI.nii | wc -w

Thanks,

  • rick
5

Hello.
Below is the outputs you requested.

3dAttribute TAXIS_OFFSETS CON06_ACQ.nii

*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as /Volumes/T7/CON06_ACQ.nii,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:/Volumes/T7/CON06_ACQ.nii is 2.817584 degrees from plumb.
0.945 1.95 0.885 1.89 0.8275 1.83 0.7675 1.7725 0.71 1.7125 0.65 1.655 0.59 1.595 0.5325 1.535 0.4725 1.4775 0.415 1.4175 0.355 1.3575 0.295 1.3 0.2375 1.24 0.1775 1.1825 0.1175 1.1225 0.06 1.0625 0 1.005

===============

nifti_tool -disp_hdr -field slice_code -infiles CON06_ACQ.nii

N-1 header file ‘CON06_ACQ.nii’, num_fields = 1
name offset nvals values

slice_code 122 1 0

(I think the slice code should be 6…–interleaved, descending, starting w/ the 2nd to the last slice)

===============

3dinfo -nk CON06_ACQ.nii
34

===============

3dAttribute TAXIS_OFFSETS CON06_ACQ.nii | wc -w
*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as /Volumes/T7/CON06_ACQ.nii,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:/Volumes/T7/CON06_ACQ.nii is 2.817584 degrees from plumb.
34

Thank you

6

That NIFTI field could certainly be changed to 6.

nifti_tool -mod_hdr -mod_field slice_code 6 \
      -infiles CON06_ACQ.nii -prefix MOD.nii

However getting back to the original question, I expect it is moot. It seems most likely that there isn’t any real problem in the first place, but that you might have mis-clicked in getting the timing from the graph viewer. I cannot see how the timing would be messed up.

Also, is there a JSON sidecar with timing included? It would be good to verify that it matches with what is in the NIFTI dataset.

  • rick