Hi Pierre,

I have a question regarding the slice order that you compute for the slice timing correction.
I have fMRI data recorded on a GE discovery 3T scanner. Each frame we record has 33 slices, using the interleaved option, the direction of acquisition is from superior to inferior.

I expected the slice order to be:
[1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32]

But NIAK gave me this answer:
Why is it the case? I know that the slice order for Siemens recording changes with the direction of the acquisition (see http://www.healthcare.siemens.com/siemen...). Is it the same for GE? Do you have any documentation about it?

Thanks a lot
Tanguy

Hi Tanguy,

The important bit is the following:

Slices are defined along the z axis
The step along this axis is : -3.70

This means your slices are stored upside down, top of the head in the first slices, and then bottom in the last slices. The vector of slices refer to ordering in voxel space. The "interleaved" option actually means "interleaved ascending". You can force to "interleaved descending", but I am going to assume that is not what you have done. In this case, slices are acquired from the bottom of the head to the top of the head, interleaved. On GE, it defaults to odd slices first and then even. This means slice 33 (in voxel space), corresponding to the bottom of the head, was acquired first. And niak_brick_slice_timing does the correct thing. Note the the order in which slices are stored in voxel space (here from top to bottom), is independent from the order in which slices are acquired (may well be from bottom to top). I realize this may seem confusing as hell. That's because it is. 

But that's not the end of it. The story would be different on a Siemens scanner, where the odd vs even first rule for interleaved acquisitions actually depends on the number of slices used (odd -> odd first, even -> even first). WTF is right. Note that this is based on various readings I have made, but not on a deep knowledge of all sequences implemented in various scanners and software versions. There may well be many exceptions I don't know of. As Chris Roden puts it in this post (http://www.mccauslandcenter.sc.edu/CRNL/...): "you may want to test this for yourself on your system". 

To bring closure to this email, I have looked hard for a reference I read years ago, but unfortunately failed to find it. But I remember the main conclusions, which I can report. It was an HBM abastract in which the authors had a subject move in the scanner, so they could infer for sure the order of slice acquisitions. They tried a couple different configurations, and compared what they thought they were doing based on parameters on the console, to what they were actually doing. Turned out that in several cases, it did not match. As far as I know, this was never turned into a paper despite being quite illuminating. Even if in the end the authors misunderstood some console parameters, latter realized their mistake and decided not to write a paper to avoid embarrassing themselves, it still goes to show how confusing those parameters are.  

At this point, my general take on slice timing correction is that it is really, really easy to get it wrong. I would recommend double checking with your MR technician that you used an "interleaved descending" acquisition as you indicated (quote: "the direction of acquisition is from superior to inferior"). If it's the case, then code 'interleaved_descending" in niak_brick_slice_timing and you should get the slice times you were expecting. But until I find a good way to diagnose the quality of slice timing correction, which I currently don't have, I will be very suspicious about that step. I generally end up not implementing it in most cases, because (1) correcting it with the wrong parameters will actually be worse than not correcting it; (2) it has little impact on functional connectivity anyway. 

I hope this is helpful,

Pierre

Hi Pierre,

Thank you for this fast and detailed answer, that helped a lot!

Tanguy

Dear Pierre,

I tried to understand better the slice timing orders, and as far as I understood,
If z-step is positive, the MINC numbering system is F>>H (bottom to top).
If z-step is negative, the MINC numbering system is H>>F (top to bottom).
During the slice timing correction in NIAK, it (1) reads the z-step information from the header and (2) requires users to identify the acquisition method.


Therefore I expect the slice order in each case, as follows.

======================================================================
[Table 1] In the F>>H slice numbering system, the top slice (top head) is labeled as N, and the bottom (neck) is labeled as 1. Then, the slice timing orders in the systems are determined as follows.
Sequential ascending (N)                             [1:N]
Sequential descending (N)                           [N:1]
Interleaved ascending (N is odd)                  [1:2:N 2:2:N-1]
Interleaved ascending (N is even)                [2:2:N 1:2:N-1]
Interleaved descending (N is odd)                [N:-2:1 N-1:-2:2]
Interleaved descending (N is even)               [N:-2:2 N-1:-2:1]


[Table 2] In the H>>F slice numbering system, the top slice (top head) is labeled as 1, and the bottom (neck) is labeled as N. Then, the slice timing orders in the systems are determined as follows.
Sequential ascending (N)                              [N:1]
Sequential descending (N)                            [1:N]
Interleaved ascending (N is odd)                   [N:-2:1 N-1:-2:2]
Interleaved ascending (N is even)                  [N:-2:2 N-1:-2:1]
Interleaved descending (N is odd)                 [1:2:N 2:2:N-1]
Interleaved descending (N is even)                [2:2:N 1:2:N-1]
======================================================================

I tested NIAK-boss-0.13.0 using the three different images.

mincinfo myEPI_1.mnc.gz had N=33 slices and a negative z-step=-3.7;      >> I expect that NIAK should refer to Table 2.
mincinfo myEPI_2.mnc.gz had N=33 slices and a positive z-step=3.7;        >> I expect that NIAK should refer to Table 1.
mincinfo myEPI_3.mnc.gz had N=34 slices and a negative z-step=-4.0;      >> I expect that NIAK should refer to Table 2.

While NIAK gave me the correct slice order from the two imagesc (1 and 2), it gave me one different result for the myEPI_3.mnc with even number of slices.

(3) myEPI_3.mnc

If one identified "Sequential ascending", I expect that NIAK should give me [N:1]. The result was correct:
---------------------------------------------------------------------
Slice timing scheme : sequential ascending
Slices are defined along the z axis
The step along this axis is : -4.00
The scanner type is : Siemens
The resulting slice order is :
ans =
Columns 1 through 13
34 33 32 31 30 29 28 27 26 25 24 23 22
Columns 14 through 26
21 20 19 18 17 16 15 14 13 12 11 10 9
Columns 27 through 34
8 7 6 5 4 3 2 1
---------------------------------------------------------------------


If one identified "Sequential descending", I expect that NIAK should give me [1:N]. The result was correct:
---------------------------------------------------------------------
Slice timing scheme : sequential descending
Slices are defined along the z axis
The step along this axis is : -4.00
The scanner type is : Siemens
The resulting slice order is :
ans =
Columns 1 through 13
1 2 3 4 5 6 7 8 9 10 11 12 13
Columns 14 through 26
14 15 16 17 18 19 20 21 22 23 24 25 26
Columns 27 through 34
27 28 29 30 31 32 33 34
---------------------------------------------------------------------


If one identified "Interleaved ascending", I expect that NIAK should give me [N:-2:2 N-1:-2:1]. The result was correct:
---------------------------------------------------------------------
Slice timing scheme : interleaved ascending
Slices are defined along the z axis
The step along this axis is : -4.00
The scanner type is : Siemens
The resulting slice order is :
ans =
Columns 1 through 13
34 32 30 28 26 24 22 20 18 16 14 12 10
Columns 14 through 26
8 6 4 2 33 31 29 27 25 23 21 19 17
Columns 27 through 34
15 13 11 9 7 5 3 1
---------------------------------------------------------------------


If one identified "Interleaved descending", I expect that NIAK should give me [2:2:N 1:2:N-1]. The result was incorrect:
---------------------------------------------------------------------
Slice timing scheme : interleaved descending
Slices are defined along the z axis
The step along this axis is : -4.00
The scanner type is : Siemens
The resulting slice order is :
ans =
Columns 1 through 13
1 3 5 7 9 11 13 15 17 19 21 23 25
Columns 14 through 26
27 29 31 33 2 4 6 8 10 12 14 16 18
Columns 27 through 34
20 22 24 26 28 30 32 34
---------------------------------------------------------------------

I debugged the last case and found that opt.fist_number was set 'odd' by default, and it skipped the loop %First number because it was not empty.

% First number
if isempty(opt.first_number)
......
end

Maybe this is why? I'm also wondering whether my expectations in the two tables were correct or not.

Best regards,
Kangjoo