Deriving Slice Timing Order from Philips PAR REC and console information

, ,
1

Hello, I need to derive the slice acquisition order/ slice timing for some Philips PAR/REC data (I am getting the BIDS validator error relating to this). I’ve read through the informative Heudiconv: no extraction of slice-timing data based on Philips DICOMs post. However, most of it deals with Philips DICOMS, from which you can glean the slice order (even if from UIDs), rather than from PAR files/Philips console report. Other posts and helpful scripts also assume that you either already know the order, or have this in a header file to calculate the slice timing values.

I have some clues as to how to derive order information from the PAR file/ scanner report, but I wanted someone with knowledge on the subject to confirm this (or not).

Relevant fields from the console report:

. Patient position : Head First Supine
. Preparation direction : Anterior-Posterior
. Repetition time [ms] : 2200.000
SENSE = “yes”;
P reduction (AP) = 2.5;
MB SENSE = “no”;
Stacks = 1;
type = “parallel”;
slices = 38;
Slice scan order = “HF”;
TR = “user defined”;
(ms) = 2200;
Temporal slice spacing = “equidistant”;
Packages = 1;

and from the PAR file

slice orientation ( TRA/SAG/COR ) = 1

My assumptions are as follows:

  • Slice Scan Order = HF = Head-to-foot = Descending, which added to the PAR file slice orientation = 1, (axial), would mean the order are axial slices descending from head to foot (this is crucial, but only an educated guess).

  • Since Packages = 1, looking at the SPM wikibooks entry, this should simply be a descending 4,3,2,1 order.

  • I am also assuming that this was not a multiband acquisition since MB SENSE is turned off, that “regular” SENSE does not affect slice timing, and that temporal slice spacing = “equidistant” means ther are no temporal gaps.

Hence, it would seem that slice timings would simply be derived from sequentially subtracting the TA (2.2s/38slices) from each slice starting at (but excluding) 2.2s until zero.

@drmclem, could you kindly confirm this? I am making an educated guess on all of this, but would really appreciate confirmation on the console values, as I was not involved in data acquisition, and only have this to go by. Many thanks in advance!!

2

I think packages are only the number of slabs / TR. You need the Slice scan order = “ascend”, “decend” or “default” for the Philips interleaved order. I found this information in the text export of the scan protocol

3

@cni-md, thanks for your suggestions. I mentioned the packages because the link in the SPM wikibooks site on slice timing has a table where mode and packages are used to derive the order.

As far as the Slice Scan Order field (from the same protocol txt you mention), the value I get is = “HF” which is why I am asking whether it stands for head to feet and whether ir is equivalent to “descending”

4

Here is a Matlab script for computing slice timing for non-multiband data:

TRsec = 3;
nSlices = 48;
TA = TRsec/nSlices; %assumes no temporal gap between volumes
bidsSliceTiming=[0:TA:TRsec-TA]; %ascending
if false %descending
bidsSliceTiming = flip(bidsSliceTiming);
end
if true %interleaved
order = [1:2:nSlices 2:2:nSlices]
bidsSliceTiming(order) = bidsSliceTiming;
end
%report results
fprintf(’ “SliceTiming”: [\n’);
for i = 1 : nSlices
fprintf(’ %g’, bidsSliceTiming(i));
if (i < nSlices)
fprintf(’,\n’);
else
fprintf(’ ],\n’);
end
end

Here I assume that there is no temporal gap between volumes. This will not be the case for sparse sequences (GE refers to this as Group Delay, Siemens as Delay in TR). Also, Philips users should be aware that the Prospective Motion Correction option adds a slight pause between volumes. My experience is that this is usually very brief (~17ms) so can probably be ignored.

Multi-band patterns can be a bit unusual, and to determine these you probably need help from the vendor. For example, with GE the pattern changed with 27.0 R3 to minimize interference between volumes. Therefore, for GE you need to not only know the multi-band factor, but the software stepping as well.

5

Thanks @Chris_Rorden… That is a neat script! I just need to make sure my data is indeed in descending sequential order before I use it.