open-discussion > Slice Timing Correction Info
Showing 1-21 of 21 posts
Feb 21, 2013 02:02 PM | Rocco Marchitelli
Slice Timing Correction Info
Hello Everybody,
I was wondering what should be inserted in the slice time correction label in setup_pestica.sh for different scanners (General Electrics and Philips) and the way slices were acquired.
Is there any standard for that?
Thanks in advance,
Rocco
I was wondering what should be inserted in the slice time correction label in setup_pestica.sh for different scanners (General Electrics and Philips) and the way slices were acquired.
Is there any standard for that?
Thanks in advance,
Rocco
Feb 21, 2013 08:02 PM | Erik Beall
RE: Slice Timing Correction Info
Hi Rocco,
I believe for both GE and Philips MRI scanners, it depends on whether you've selected sequential or interleaved when you acquired the data. If you're doing interleaved acquisitions, you can use 'alt-asc'. If you have selected sequential, then use 'seq-asc' (it might be possible to do descending sequential, but I don't know).
For interleaved, Siemens is a bit weird in that interleaved acquisitions start on the first slice if you have an odd number of total slices, but on the second slice if you have an even number. There is also an extra 20msec gap on Siemens scanners that have PACE installed, and the option 'siemens-alt-asc' accounts for this. Its a tiny tiny effect and you'd probably get the same result either way.
Erik
I believe for both GE and Philips MRI scanners, it depends on whether you've selected sequential or interleaved when you acquired the data. If you're doing interleaved acquisitions, you can use 'alt-asc'. If you have selected sequential, then use 'seq-asc' (it might be possible to do descending sequential, but I don't know).
For interleaved, Siemens is a bit weird in that interleaved acquisitions start on the first slice if you have an odd number of total slices, but on the second slice if you have an even number. There is also an extra 20msec gap on Siemens scanners that have PACE installed, and the option 'siemens-alt-asc' accounts for this. Its a tiny tiny effect and you'd probably get the same result either way.
Erik
Apr 15, 2013 01:04 PM | Pouya Ghaemmaghami
RE: Slice Timing Correction Info
Dear Eric and All,
I have two questions regarding slice timing.
In the last released of Pestica, you recommend using Pestica after motion correction and before doing any kind of blurring (smoothing and etc) Now i want to know should we do it also before slice timing correction or after that? I'm asking this becasue people generally do slice timing correction at the same time of motion correction with -tshift option in 3dvolreg command.
my second question is related to interleaved slices. as you know we have two types of interleaved ascending as follows:
ascending interleaved with even slices first, then odd slices if the number of slices acquired is even (2,4,6,8,...end; 1,3,5,7,..end-1)
ascending interleaved with odd slices first, then even slices if the number of slices acquired is odd (1,3,5,7,...end; 2,4,6,8,..end-1)
also in afni, while we make afni dataset(using to3d) we need to mention which types are the slices: alt+z either alt+z2
is there anyway to mention this in pestica? to be precise can we set it in Pestica set up files in this way: siemens_alt_asc_odd (even) ??
I think this would be very helpful?
I have two questions regarding slice timing.
In the last released of Pestica, you recommend using Pestica after motion correction and before doing any kind of blurring (smoothing and etc) Now i want to know should we do it also before slice timing correction or after that? I'm asking this becasue people generally do slice timing correction at the same time of motion correction with -tshift option in 3dvolreg command.
my second question is related to interleaved slices. as you know we have two types of interleaved ascending as follows:
ascending interleaved with even slices first, then odd slices if the number of slices acquired is even (2,4,6,8,...end; 1,3,5,7,..end-1)
ascending interleaved with odd slices first, then even slices if the number of slices acquired is odd (1,3,5,7,...end; 2,4,6,8,..end-1)
also in afni, while we make afni dataset(using to3d) we need to mention which types are the slices: alt+z either alt+z2
is there anyway to mention this in pestica? to be precise can we set it in Pestica set up files in this way: siemens_alt_asc_odd (even) ??
I think this would be very helpful?
Apr 15, 2013 01:04 PM | Erik Beall
RE: Slice Timing Correction Info
Unless you're acquiring really fast volumes (less than few hundred
msec or so), the slice timing correction will make physiologic
noise in your data unrecoverable by any means. The slice time
correction resamples the data acquired at X msec after the start of
the volume and assumes that everything is Nyquist-sampled (ie. no
freq higher than 1/(2*TR) Hz). Any frequency lower than the
Nyquist is correctly resampled as if it occurred at the start of
the volume. However, any frequency in the data that is higher
than the Nyquist gets smeared all over the Fourier spectrum
randomly depending on where it happened to bin. Most
(possibly anything slower than 200-400msec TR, due to higher
harmonics of cardiac) acquisitions do not have a volumetric sample
rate fast enough to capture physiologic noise. If you do a
regression-removal correction (stage 4+5 of PESTICA script), then
in theory this noise will have been removed, and you can then do
slice-time correction after PESTICA. You mention combining
moco and slice time, if your motion is pretty low level, then you
could do motion correction after PESTICA (see Jones TB, Bandettini
PA & Birn RM (2008) Integration of motion correction and
physiological noise regression in fMRI. Neuroimage 42:582-590.).
For the slice timing order, if you specify siemens_alt_asc, then it detects whether you've got an even or odd number of slices and correctly follows the Siemens slice timing. It ignores the AFNI timing header, as these are rarely populated correctly. So if you're using the default siemens ep2d sequence with interleaved ascending, just use the default siemens_alt_asc and it will use the correct slice timing. In AFNI, if you're using slice timing correction later, however, then you will need to use the appropriate alt+z or alt+z2 otherwise slice timing will be incorrect. PESTICA should be copying all the header information, but I've not tested this specifically. Does it work for you?
Erik
For the slice timing order, if you specify siemens_alt_asc, then it detects whether you've got an even or odd number of slices and correctly follows the Siemens slice timing. It ignores the AFNI timing header, as these are rarely populated correctly. So if you're using the default siemens ep2d sequence with interleaved ascending, just use the default siemens_alt_asc and it will use the correct slice timing. In AFNI, if you're using slice timing correction later, however, then you will need to use the appropriate alt+z or alt+z2 otherwise slice timing will be incorrect. PESTICA should be copying all the header information, but I've not tested this specifically. Does it work for you?
Erik
Apr 15, 2013 02:04 PM | Pouya Ghaemmaghami
RE: Slice Timing Correction Info
Thanks Eric,
but i didnt get one point clearly. you siad that in most cases (like my case, that i have TR 2200 ms) you think that there is no difference between running slice timing correction before or after running pestica. Actually in my case i mixed moco with -tshift option and then i executed pestica. Do you think its fine? or it better to do moco, then pestica and then slice timing correction?
Best,
Pouya
but i didnt get one point clearly. you siad that in most cases (like my case, that i have TR 2200 ms) you think that there is no difference between running slice timing correction before or after running pestica. Actually in my case i mixed moco with -tshift option and then i executed pestica. Do you think its fine? or it better to do moco, then pestica and then slice timing correction?
Best,
Pouya
Apr 15, 2013 02:04 PM | Erik Beall
RE: Slice Timing Correction Info
Whoa sorry about that, I think I confused the issue. DO NOT run
slice timing correction before PESTICA no matter what. It
will make any physiologic noise correction work poorly (even if you
used pulse and breathing monitors to record the physiologic signals
instead of PESTICA). I think its safest to do moco, then
PESTICA, then slice timing correction.
Erik
Erik
Jul 25, 2013 06:07 PM | Will Foran
RE: Slice Timing Correction Info
For total clarity, after motion correcting and running pestica.
Slicetime correction needs to be applied. But AFNI's 3dTshift won't
do it. FSL's slicetimer will though.
Is this correct?
++ 3dTshift: AFNI version=AFNI_2011_12_21_1014 (Jul 12 2013) [64-bit]
*+ WARNING: dataset is already aligned in time!
Is this correct?
» 3dinfo 104_rest.moco.irfretroicor+orig.
----- HISTORY -----
[...] to3d -prefix rest.nii -time:zt 29 200 1.5sec alt+z 012-0001-00001-0.dcm 012-0002-00002-0.dcm 012-0003-00003-0.dcm ... 012-0199-00199-0.dcm 012-0200-00200-0.dcm
[...] 3dresample -orient LPI -prefix rest.nii.gz -inset rest.nii.gz
[...] 3dvolreg -prefix 104_rest.moco -base 'rest.nii.gz[0]' -dfile 104_rest_motion.txt -maxite 60 -zpad 8 rest.nii.gz
[...] 3dcopy 104_rest.moco+orig.HEAD 104_rest.moco_pestica/104_rest.moco
[...]
/Volumes/TX/subject_data/byID/104/rest/104_rest.moco_pestica
irf_retroicor(ln137)->WriteBrik(ln549)
[3dcopy and irf_retroicor history entry is from: run_pestica.sh -d
104_rest.moco -m -b ][...] to3d -prefix rest.nii -time:zt 29 200 1.5sec alt+z 012-0001-00001-0.dcm 012-0002-00002-0.dcm 012-0003-00003-0.dcm ... 012-0199-00199-0.dcm 012-0200-00200-0.dcm
[...] 3dresample -orient LPI -prefix rest.nii.gz -inset rest.nii.gz
[...] 3dvolreg -prefix 104_rest.moco -base 'rest.nii.gz[0]' -dfile 104_rest_motion.txt -maxite 60 -zpad 8 rest.nii.gz
[...] 3dcopy 104_rest.moco+orig.HEAD 104_rest.moco_pestica/104_rest.moco
[...]
/Volumes/TX/subject_data/byID/104/rest/104_rest.moco_pestica
irf_retroicor(ln137)->WriteBrik(ln549)
» 3dTshift -overwrite -prefix
104_rest.moco.retroicor.tshift.nii.gz
104_rest.moco.irfretroicor+orig.
++ 3dTshift: AFNI version=AFNI_2011_12_21_1014 (Jul 12 2013) [64-bit]
*+ WARNING: dataset is already aligned in time!
» 3dcopy 104_rest.moco.irfretroicor+orig.
104_moco.irfret.nii.gz
» slicetimer --odd -i 104_moco.irfret.nii.gz -o 104_moco.irfret.tshift.nii.gz
» slicetimer --odd -i 104_moco.irfret.nii.gz -o 104_moco.irfret.tshift.nii.gz
Jul 30, 2013 04:07 PM | Erik Beall
RE: Slice Timing Correction Info
I'm not sure whats going on, PESTICA
uses the AFNI MATLAB library to write the data, and I'm pretty sure
I implemented copying the slice timing information correctly on to
the written data BRIK. If I grep for TAXIS_OFFSETS in the
+orig.HEAD file, I see the same offsets copied through. I ran
3dTshift on data that I'd produced with run_pestica.sh in the same
way as yours, and I didn't get the error. Are you using
PESTICA_v2? The only thing I don't have in my history is
3dresample - I didn't use it in my processing, could you try
without 3dresample? Alternatively, you could call 3dTshift
with the -tpattern option, could you try that and see if it works
on your data?
Erik
Originally posted by Will Foran:
Erik
Originally posted by Will Foran:
For total clarity, after motion correcting and
running pestica. Slicetime correction needs to be applied. But
AFNI's 3dTshift won't do it. FSL's slicetimer will though.
Is this correct?
++ 3dTshift: AFNI version=AFNI_2011_12_21_1014 (Jul 12 2013) [64-bit]
*+ WARNING: dataset is already aligned in time!
Is this correct?
» 3dinfo 104_rest.moco.irfretroicor+orig.
----- HISTORY -----
[...] to3d -prefix rest.nii -time:zt 29 200 1.5sec alt+z 012-0001-00001-0.dcm 012-0002-00002-0.dcm 012-0003-00003-0.dcm ... 012-0199-00199-0.dcm 012-0200-00200-0.dcm
[...] 3dresample -orient LPI -prefix rest.nii.gz -inset rest.nii.gz
[...] 3dvolreg -prefix 104_rest.moco -base 'rest.nii.gz[0]' -dfile 104_rest_motion.txt -maxite 60 -zpad 8 rest.nii.gz
[...] 3dcopy 104_rest.moco+orig.HEAD 104_rest.moco_pestica/104_rest.moco
[...]
/Volumes/TX/subject_data/byID/104/rest/104_rest.moco_pestica
irf_retroicor(ln137)->WriteBrik(ln549)
[3dcopy and irf_retroicor history entry is from: run_pestica.sh -d
104_rest.moco -m -b ][...] to3d -prefix rest.nii -time:zt 29 200 1.5sec alt+z 012-0001-00001-0.dcm 012-0002-00002-0.dcm 012-0003-00003-0.dcm ... 012-0199-00199-0.dcm 012-0200-00200-0.dcm
[...] 3dresample -orient LPI -prefix rest.nii.gz -inset rest.nii.gz
[...] 3dvolreg -prefix 104_rest.moco -base 'rest.nii.gz[0]' -dfile 104_rest_motion.txt -maxite 60 -zpad 8 rest.nii.gz
[...] 3dcopy 104_rest.moco+orig.HEAD 104_rest.moco_pestica/104_rest.moco
[...]
/Volumes/TX/subject_data/byID/104/rest/104_rest.moco_pestica
irf_retroicor(ln137)->WriteBrik(ln549)
» 3dTshift -overwrite -prefix
104_rest.moco.retroicor.tshift.nii.gz
104_rest.moco.irfretroicor+orig.
++ 3dTshift: AFNI version=AFNI_2011_12_21_1014 (Jul 12 2013) [64-bit]
*+ WARNING: dataset is already aligned in time!
» 3dcopy 104_rest.moco.irfretroicor+orig.
104_moco.irfret.nii.gz
» slicetimer --odd -i 104_moco.irfret.nii.gz -o 104_moco.irfret.tshift.nii.gz
» slicetimer --odd -i 104_moco.irfret.nii.gz -o 104_moco.irfret.tshift.nii.gz
Jul 30, 2013 08:07 PM | Will Foran
RE: Slice Timing Correction Info
Thanks for the feedback!
It looks like 3dresample is the culprit:
It looks like 3dresample is the culprit:
» grep TAXIS_OFFSETS *HEAD -c|column
-ts:
rest+orig.HEAD 1
rest.lpi+orig.HEAD 0
rest+orig.HEAD 1
rest.lpi+orig.HEAD 0
» 3dNotes rest.lpi+orig.
----- HISTORY -----
[lncd@arnold: Tue Jul 30 16:15:54 2013] to3d -prefix rest -time:zt 29 200 1.5sec alt+z /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0001-00001-0.dcm /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0002-00002-0.dcm /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0003-00003-0.dcm ... /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0199-00199-0.dcm /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0200-00200-0.dcm
[lncd@arnold: Tue Jul 30 16:16:24 2013] 3dresample -orient LPI -prefix rest.lpi -inset rest+orig
----- HISTORY -----
[lncd@arnold: Tue Jul 30 16:15:54 2013] to3d -prefix rest -time:zt 29 200 1.5sec alt+z /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0001-00001-0.dcm /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0002-00002-0.dcm /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0003-00003-0.dcm ... /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0199-00199-0.dcm /Volumes/TX/Autism_Faces/subject_data/byID/104/rest/012-0200-00200-0.dcm
[lncd@arnold: Tue Jul 30 16:16:24 2013] 3dresample -orient LPI -prefix rest.lpi -inset rest+orig
Aug 29, 2013 09:08 PM | Angela Abbott
RE: Slice Timing Correction Info
Hello,
I have a follow up question to Rocco's post. I'm using data with interleaved acquisition (zdim: 42, TR: 2000) collected on a GE scanner, which begins at slice 1 for both even and odd number of total volumes. For slice timing, I tried using "alt-asc", however, I'm encountering an error in apply_PESTICA2, which says "??? Index exceeds matrix dimensions." Could you tell me, is there a better way to specify my slice timing parameters?
Thanks,
Angela
I have a follow up question to Rocco's post. I'm using data with interleaved acquisition (zdim: 42, TR: 2000) collected on a GE scanner, which begins at slice 1 for both even and odd number of total volumes. For slice timing, I tried using "alt-asc", however, I'm encountering an error in apply_PESTICA2, which says "??? Index exceeds matrix dimensions." Could you tell me, is there a better way to specify my slice timing parameters?
Thanks,
Angela
Aug 30, 2013 01:08 PM | Erik Beall
RE: Slice Timing Correction Info
Hm, I don't know why that could be, that is the string we look for
in the code (inside get_slice_timing.m, line 8 parses like
Can you copy and send me the matlab line that is echoed to the screen when apply_PESTICA2 is run? For example, I get:
My first guess would be environment problem, but there are other possibilities.
Erik
if strcmp(slice_mode,'alt-asc')
). Are you setting the slice timing using:export PESTICA_SLICE_TIMING="alt-asc"
Can you copy and send me the matlab line that is echoed to the screen when apply_PESTICA2 is run? For example, I get:
matlab -nodesktop -nosplash <<<"addpath
/mnt/netScratch/ebeall/pestica_afni_v2;[card,resp]=apply_PESTICA2(15,'S40vol+orig','S40vol.brain+orig','alt-asc');
fp=fopen('card_rawest.dat','w'); fprintf(fp,'%g\n',card);
fclose(fp); fp=fopen('resp_rawest.dat','w');
fprintf(fp,'%g\n',resp); fclose(fp); exit"
My first guess would be environment problem, but there are other possibilities.
Erik
Sep 4, 2013 11:09 PM | Angela Abbott
RE: Slice Timing Correction Info
Yes, I did set the slice timing as you mentioned- "alt-asc".
This is the matlab echo line:
matlab -nodesktop -nosplash -r addpath /Users/PowerPC/pestica_afni_v1_3; [card,resp]=apply_PESTICA2(15,'131A_ep2d.moco+orig','131A_ep2d.moco.brain+orig','alt-asc'); fp=fopen('card_rawest.dat','w'); fprintf(fp,'%g\n',card); fclose(fp); fp=fopen('resp_rawest.dat','w'); fprintf(fp,'%g\n',resp); fclose(fp)
I'm using Version 1.3 (including the v1.4 update) so that it will jive with my version of AFNI.
Here is the full error message:
> In path at 110
In addpath at 87
In apply_PESTICA2 at 35
??? Index exceeds matrix dimensions.
Error in ==> apply_PESTICA2 at 68
load(sprintf('Volumes/Einstein/PestICA/131A_ep2d.moco_pestica/pestica_%dcomps_slice%d.mat',ep2d_filename(1:end-5),comps,zstart(1)),'A');
matlab -nodesktop -nosplash -r addpath /Users/PowerPC/pestica_afni_v1_3; [card,resp]=apply_PESTICA2(15,'131A_ep2d.moco+orig','131A_ep2d.moco.brain+orig','alt-asc'); fp=fopen('card_rawest.dat','w'); fprintf(fp,'%g\n',card); fclose(fp); fp=fopen('resp_rawest.dat','w'); fprintf(fp,'%g\n',resp); fclose(fp)
I'm using Version 1.3 (including the v1.4 update) so that it will jive with my version of AFNI.
Here is the full error message:
> In path at 110
In addpath at 87
In apply_PESTICA2 at 35
??? Index exceeds matrix dimensions.
Error in ==> apply_PESTICA2 at 68
load(sprintf('Volumes/Einstein/PestICA/131A_ep2d.moco_pestica/pestica_%dcomps_slice%d.mat',ep2d_filename(1:end-5),comps,zstart(1)),'A');
Sep 5, 2013 09:09 PM | Angela Abbott
RE: Slice Timing Correction Info
You were right- it looks like there was an error with the
environmental variables and the startup script. Thanks for
your help.
Sep 11, 2013 06:09 PM | Erik Beall
RE: Slice Timing Correction Info
No problem, I just returned from vacation and was catching
up! Glad you figured it out, the startup script and
associated code are not the best at checking things have been set
up.
Erik
Erik
Oct 7, 2013 02:10 PM | Rocco Marchitelli
RE: Slice Timing Correction Info
Hello Erik,
Thanks for the reply on the issue regarding the coregistration between the EPI and the EPI-MNI template.
I will give you some feedback after trying the -cmass option.
I come back to slice-timing topic now because I have to apply PESTICA to EPI data from Philips scanner.
Now the problem is that I believe that NONE of the available strings in the PESTICA setup might account for Philips slice timing correction (correct me weather I am wrong).
For Philips data there is indeed a special sequence in which slices were acquired. The sequence is the following:
0 472,5 945 1417,5 1890 2295 67,5 540 1012,5 1485 1957,5 2362,5 135 607,5 1080 1552,5 2025 2430 202,5 675 1147,5 1620 2092,5 2497,5 270 742,5 1215 1687,5 2160 2565 337,5 810 1282,5 1755 2227,5 2632,5 405 877,5 1350 1822,5
Is there a way to setup PESTICA with this slice-timing configuration?
Thanks,
R.
Thanks for the reply on the issue regarding the coregistration between the EPI and the EPI-MNI template.
I will give you some feedback after trying the -cmass option.
I come back to slice-timing topic now because I have to apply PESTICA to EPI data from Philips scanner.
Now the problem is that I believe that NONE of the available strings in the PESTICA setup might account for Philips slice timing correction (correct me weather I am wrong).
For Philips data there is indeed a special sequence in which slices were acquired. The sequence is the following:
0 472,5 945 1417,5 1890 2295 67,5 540 1012,5 1485 1957,5 2362,5 135 607,5 1080 1552,5 2025 2430 202,5 675 1147,5 1620 2092,5 2497,5 270 742,5 1215 1687,5 2160 2565 337,5 810 1282,5 1755 2227,5 2632,5 405 877,5 1350 1822,5
Is there a way to setup PESTICA with this slice-timing configuration?
Thanks,
R.
Oct 8, 2013 06:10 PM | Erik Beall
RE: Slice Timing Correction Info
Hi Rocco,
the script run_pestica.sh should pick it up, as long as the timing is specified in the header file. To check, do you get this same timing information if you run:
3dAttribute TAXIS_OFFSETS
If this works, then make sure you have unset PESTICA_SLICE_TIMING prior to running run_pestica.sh on your data - to do this, you can type
unset PESTICA_SLICE_TIMING
and then run_pestica.sh script should pick it up correctly. Isaac Schwabacher figured out how to do this automatically, and I am in his debt. However, I've only tested this on my data, let me know if you get good cardiac and respiratory estimators after doing this (it should be very different and much better if it works, it should fail catastrohpically if it doesn't work and not give you anything. If you have any doubt, send me the card/resp_rawest.txt files and the pestica2_matrices_comps.mat files and I can check). apply_PESTICA2 (stage 2) uses this information, as do the RETROICOR/IRF-RETROICOR noise removal methods (stage 4-5).
Erik
Originally posted by Rocco Marchitelli:
the script run_pestica.sh should pick it up, as long as the timing is specified in the header file. To check, do you get this same timing information if you run:
3dAttribute TAXIS_OFFSETS
If this works, then make sure you have unset PESTICA_SLICE_TIMING prior to running run_pestica.sh on your data - to do this, you can type
unset PESTICA_SLICE_TIMING
and then run_pestica.sh script should pick it up correctly. Isaac Schwabacher figured out how to do this automatically, and I am in his debt. However, I've only tested this on my data, let me know if you get good cardiac and respiratory estimators after doing this (it should be very different and much better if it works, it should fail catastrohpically if it doesn't work and not give you anything. If you have any doubt, send me the card/resp_rawest.txt files and the pestica2_matrices_comps.mat files and I can check). apply_PESTICA2 (stage 2) uses this information, as do the RETROICOR/IRF-RETROICOR noise removal methods (stage 4-5).
Erik
Originally posted by Rocco Marchitelli:
Hello Erik,
Thanks for the reply on the issue regarding the coregistration between the EPI and the EPI-MNI template.
I will give you some feedback after trying the -cmass option.
I come back to slice-timing topic now because I have to apply PESTICA to EPI data from Philips scanner.
Now the problem is that I believe that NONE of the available strings in the PESTICA setup might account for Philips slice timing correction (correct me weather I am wrong).
For Philips data there is indeed a special sequence in which slices were acquired. The sequence is the following:
0 472,5 945 1417,5 1890 2295 67,5 540 1012,5 1485 1957,5 2362,5 135 607,5 1080 1552,5 2025 2430 202,5 675 1147,5 1620 2092,5 2497,5 270 742,5 1215 1687,5 2160 2565 337,5 810 1282,5 1755 2227,5 2632,5 405 877,5 1350 1822,5
Is there a way to setup PESTICA with this slice-timing configuration?
Thanks,
R.
Thanks for the reply on the issue regarding the coregistration between the EPI and the EPI-MNI template.
I will give you some feedback after trying the -cmass option.
I come back to slice-timing topic now because I have to apply PESTICA to EPI data from Philips scanner.
Now the problem is that I believe that NONE of the available strings in the PESTICA setup might account for Philips slice timing correction (correct me weather I am wrong).
For Philips data there is indeed a special sequence in which slices were acquired. The sequence is the following:
0 472,5 945 1417,5 1890 2295 67,5 540 1012,5 1485 1957,5 2362,5 135 607,5 1080 1552,5 2025 2430 202,5 675 1147,5 1620 2092,5 2497,5 270 742,5 1215 1687,5 2160 2565 337,5 810 1282,5 1755 2227,5 2632,5 405 877,5 1350 1822,5
Is there a way to setup PESTICA with this slice-timing configuration?
Thanks,
R.
Dec 19, 2013 04:12 PM | Rocco Marchitelli
RE: Slice Timing Correction Info
Ciao Erik,
thanks, it seems it worked efficiently.
here I attach the three files you mentioned in the previous message.
Let me know
R.
thanks, it seems it worked efficiently.
here I attach the three files you mentioned in the previous message.
Let me know
R.
Dec 19, 2013 04:12 PM | Rocco Marchitelli
RE: Slice Timing Correction Info
pestica2_matrices_15comps.mat
attached
attached