Add Time Slicing data to Nifti file

AFNI Message Board
1

Dear AFNI experts,
Due to some software issue of the MRI machine, our time slicing data was lost in the original DICOM files. I know the slice scan order is alt+z = altplus = alternating in the plus direction. So I got the time info by calculating the slice creation time. I want to add this info to the Nifti files. Is it possible? Anyone encounter this issue before? I am trying to do this by Python.
The data were acquired on a whole-body Philips 3.0T Acheva TX.

Thanks.

Best,
Xiyue

2

The AFNI tool that allows you to do this is 3dTcat.


-tpattern PATTERN = Specify the timing pattern for the output
                       dataset, using patterns described in the
                       'to3d -help' output (alt+z, seq, alt-z2, etc).

If you want the “pure” python way of doing this - you could use nibable to read/write the NIFTI file and set_slice_times.

Per usual, the AFNI way is easier. You could certainly wrap the AFNI command in Python.

3

Thank you. I tried
3dTcat -prefix test -tpattern altplus S004.nii
But the time is still 0 for all slices. I saw 3drefit in the help text of 3dTcat. Is that the one you recommend? 3drefit -Tslices a b c d …

4

Hmmm… What’s your AFNI version?


afni -ver

May need you to upload the data so we can take a look at it. I’ll send you a PM with instructions to upload.

5

It’s Precompiled binary macos_10.12_local: Apr 16 2021 (Version AFNI_21.1.02 ‘Domitian’)

6

Ok. Sent you a private message on the board for uploading the data. I’ll take a closer look.

-PM

7

I tried


3drefit -Tslices 'test.1D' 'S004.rs.nii'

The nii file has 9000 slices. I stored 9000 datapoint (calculated by TR/volumn#200) in test.1D file, it’s readable by AFNI.
But it says:

8

You’ll need to use backquotes to expand what’s in the 1D file.


** If you have the slice time offsets stored in a text file
                   as a list of values, then you can input these values on
                   the command line using the Unix backquote operator, as in
                     -Tslices `cat SliceTimes.1D`

9000 slices sounds like a lot…

9

The BOX website says: “This shared file or folder link has been removed or is unavailable to you.”
Could you resend it? Thank you

Xiyue

10

Sent.

11

Ok - so a few things going on… The dataset has 45 slices and 200 TRs, with a TR of 2.5s. So the test45.1D file you uploaded has the correct number of slices but is just in an ascending format (seqplus). The test.1D file has far too much data in it for what is represented in the dataset. It also looks to be ascending (instead of alt+z) and just repeated over and over again.

Since you said in the first post that your data was in alt+z/altplus, I ran 3dTcat on it with the -tpattern option I get the corrected dataset. Details below!


3dTcat -prefix test -tpattern altplus S014.rs.nii

And now to check the slice timing in the file:


3dinfo -VERB test+orig.
++ 3dinfo: AFNI version=AFNI_21.1.20 (Jun 28 2021) [64-bit]

Dataset File:    test+orig
Identifier Code: AFN_YduHKs1OxYiWsJukmYMxwg  Creation Date: Thu Jul  8 11:18:30 2021
Template Space:  ORIG
Dataset Type:    Echo Planar (-epan)
Byte Order:      LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode:    BRIK
Storage Space:   115,200,000 (115 million) bytes
Geometry String: "MATRIX(2.994091,-0.131374,-0.134763,-114.1122,-0.117991,-2.983872,0.287379,105.7399,0.146623,0.281513,2.983162,-35.87391):80,80,45"
Data Axes Tilt:  Oblique (6.073 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:  -114.112 [R] -to-   122.888 [L] -step-     3.000 mm [ 80 voxels]
A-to-P extent:  -131.260 [A] -to-   105.740 [P] -step-     3.000 mm [ 80 voxels]
I-to-S extent:   -35.874 [I] -to-    96.126 [S] -step-     3.000 mm [ 45 voxels]
R-to-L center:     4.388 [L]
A-to-P center:   -12.760 [A]
I-to-S center:    30.126 [S]
Number of time steps = 200  Time step = 2.50000s  Origin = 0.00000s  Number time-offset slices = 45  Thickness = 0.000
Time-offsets per slice: 0.000 1.278 0.056 1.333 0.111 1.389 0.167 1.444 0.222 1.500 0.278 1.556 0.333 1.611 0.389 1.667 0.444 1.722 0.500 1.778 0.556 1.833 0.611 1.889 0.667 1.944 0.722 2.000 0.778 2.056 0.833 2.111 0.889 2.167 0.944 2.222 1.000 2.278 1.056 2.333 1.111 2.389 1.167 2.444 1.222
. . .

Let me know if you can’t replicate this process! You can easily convert the AFNI dataset back to NIFTI using 3dcopy.

12

I tried this


rs_fMRI_S004_nii xiyuezh$ 3drefit -Tslices `cat Test45.1D` 'S014.rs.nii'

and it works. The nii data is 45 slices * 200 volumn. AFNI count it as 45 slices. The 1D file actually has 45 timepoints.

But when I open S014.rs.nii, the time info of each slice is still 0. I am wondering where to find the time info added.
Is this t the right place for time slicing?
https://i.ibb.co/Z2rRBkc/Screen-Shot-2021-07-08-at-11-49-34-AM.png

13

And yes, that should work just fine. Except that it looks like the text file (test45.1D) isn’t representing the altplus/alt+z timing information. Instead it just goes from slice 1 to slice 45 in an ascending way.

So if the data is actually ascending you could use -tpattern seqplus. If it’s supposed to be altplus or alt+z then you should use that information or a text file that appropriately represents it.

The @t is the TR time, e.g. index * TR.

To view the slice timing info, you can use 3dinfo -VERB.


3dinfo -VERB test+orig.

or -slice_timing


3dinfo -slice_timing test+orig.
14

Thank you Peter. Now the time slicing data is added to the file.


3dinfo -slice_timing S014.rs.nii

0.055000|0.110000|0.165000|0.220000|0.275000|0.330000|0.385000|0.440000|0.495000|0.550000|0.605000|0.660000|0.715000|0.770000|0.825000|0.880000|0.935000|0.990000|1.045000|1.100000|1.155000|1.210000|1.265000|1.320000|1.375000|1.430000|1.485000|1.540000|1.595000|1.650000|1.705000|1.760000|1.815000|1.870000|1.925000|1.980000|2.035000|2.090000|2.145000|2.200000|2.255000|2.310000|2.365000|2.420000|2.475000

Actually I am following the Slice Timing Correction tutorial here:
https://www.youtube.com/watch?v=V0aDOnIajcQ&ab_channel=AndrewJahn
According to the video, the @t is suppose to be different among slices. But now in the graph, it’s 0 everywhere. Is there any place I could check time slicing on AFNI image?

Thanks.

15

Hi Peter,
Sorry I made a mistake of the tparttern info. It should be seqplus.


3dTcat -prefix test18 -tpattern seqplus S018.rs.nii
3dinfo -slice_timing test18+orig

Then I got


0.000000|0.055556|0.111111|0.166667|0.222222|0.277778|0.333333|0.388889|0.444445|0.500000|0.555556|0.611111|0.666667|0.722223|0.777778|0.833334|0.888889|0.944445|1.000000|1.055556|1.111112|1.166667|1.222223|1.277778|1.333334|1.388889|1.444445|1.500001|1.555556|1.611112|1.666667|1.722223|1.777779|1.833334|1.888890|1.944445|2.000001|2.055556|2.111112|2.166667|2.222223|2.277779|2.333334|2.388890|2.444445

But when open in AFNI graph. For the sagittal and coronal slices, in the first volumn, @t is supposed to be same as the slicing time. I need to do a time slicing correction to it then @t is corrected to be 0. Right?
https://i.ibb.co/QdmDcV8/Screen-Shot-2021-07-12-at-1-23-26-PM.png

Thanks.
Xiyue

16

Hi Xiyue,

It looks like there is confusion in the AFNI header in this case, we will have to review it.
But after running 3dTcat to create a NIFTI dataset, remove the old extension.

3dTcat -prefix epi.timing.nii -tpattern seqplus epi.notiming.nii
nifti_tool -rm_ext ALL -overwrite -infiles epi.timing.nii

Sorry for the confusion,

  • rick
17

Hi Rick,

Sorry I am new to AFNI. I don’t understand why to remove the extension.
By using


nifti_tool -disp_hdr -infile epi.timing.nii

Before and after


nifti_tool -rm_ext ALL -overwrite -infiles epi.timing.nii

The only difference is

Before:
vox_offset 108 1 12304.0
After:
vox_offset 108 1 352.0

Dose this affect time slicing in AFNI graph?

18

Yes, the NIFTI header extension (separate from the AFNI info) seems to be throwing off the AFNI viewer. Once you remove the header you should be able to see the slice timing in the graph view of AFNI like Andy demonstrates.

19

Yeahhh!!! Thank you so much. Now it works. Even though I don’t understand the meanning of


vox_offset           108      1    352.0
20

The vox_offset is the number of bytes into the .nii file that the voxel data starts at.
In the no-extension case, the offset is 352, which is the size of the nifti header structure.
Originally, the offset also included space for the AFNI extension.

The vox_offset has no impact on anything, except to tell the NIFTI library where the data begins.

  • rick