Has the EPI data already been corrected for differences in slice timing information? If not, is this information available?

No slice time correction has been applied. The only preprocessing done to the EPI data involved orientation to RPI and removal of the first 5 timepoints. This information is also listen in the Preprocessing document which can be found in under "Docs".

For most releases slice time information can be found in the NIFTI header.

Thanks for the information. We're anxious to get started looking at this data. I've looked through the header information using nifti_tool, and I still can not find the slice timing information. I've used this command to look at all the datasets:

nifti_tool -disp_hdr -infile_spec rest_sub*.nii.gz | grep slice_code

The slice_code field would require slice_duration to be set too, but that is set to 0.0. If you have the timing by site (alt+z, for instance), we could use that. There is some more info about slice timing information in NIFTI files at these links:

http://nifti.nimh.nih.gov/nifti-1/docume... (see FAQ 20)

http://nifti.nimh.nih.gov/nifti-1/docume...

While most sites provided dicom raw data, several sites only had analyze format data. The slice_code field could not be set up with slice_duration info. As an initial effort, we did not have the slice timing information for all sites. Thus, in our initial demonstration on usage of these datasets, which is in submission now, we did not include slice timing in the data preprocessing. If possible, we will inquire such information from sites.

Thanks. If you have an estimate of how long this would take to get the slice timing information, that would be great.

We have also noticed that many datasets have a TR of 1.0 seconds and considered this to be unlikely. I wrote this short script to look at the NIFTI header for a TR of 1. Within the 3T data, 147 rest EPI datasets seem to have a TR of 1.0 seconds. Do you have information about this as well?

#!/bin/tcsh
# findTR1.csh
set tr1_dsets = 0

foreach rd (rest*.nii.gz)
nifti_tool -disp_hdr -infile_spec $rd |grep pixdim |grep "1.0 0.0 0.0" \
>& /dev/null
if ( ! $status ) then
echo "$rd has TR=1"
@ tr1_dsets++
endif
end
echo ""
echo "Found $tr1_dsets with a TR of 1"

Dan,

We appreciate your bringing this concern to our attention and providing your script. We have reviewed the datasets using the modified script below. We found 78 files with a TR = 1.0, located at New Haven, Berlin (Margulies) and Pittsburgh. We reviewed the information provided to us from those sites, and found that New Haven was set correctly, while Berlin (Margulies) should have been 2.3 sec and Pittsburgh should have been 1.5 sec. We apologize for this error that seemed to arise in the final conversion process for the upload. We will notify the larger community in the form of a news update and correct the files on the site immediately. We will also provide TR information in the site titles and in the form of a table to be included in documentation. If you find any further disparities, please do not hesitate to contact us.

Thanks,
Mike


WORKDIR=/home/gandalf/Multisite_release_NITRC
SITE_LIST=${WORKDIR}/ckTRs/Sites_list.txt
for site in `cat ${SITE_LIST}`
do
cd ${WORKDIR}/${site}
SUBJECT_LIST=${site}_subjects.txt
rm -f ${site}_pixdim.txt
for subject in `cat ${SUBJECT_LIST}`
do
echo "${site} ..."
nifti_tool -disp_hdr -infile_spec ${subject}/func/rest.nii.gz | grep pixdim >> ${site}_pixdim.txt
done
done

Thanks for the information. That will definitely help. I still find 147 3T datasets with TR of 1 second. A few other sites seem to have that TR also including Ann Arbor a and b and Berlin (Schmidt). This is the updated version of my script for checking the sites. I've attached the site list with TR of 1 and the corresponding subjects.

#!/bin/tcsh
# findTR1.csh
set tr1_dsets = 0

foreach rd (rest*.nii.gz)
nifti_tool -disp_hdr -infile_spec $rd |grep pixdim |grep "1.0 0.0 0.0" \
>& /dev/null
if ( ! $status ) then
echo "$rd has TR=1"
# strip off "rest_" and ".nii.gz" from name
set sub = `echo $rd | awk -F '.' '{print $1 }' | awk -F "_" '{print $2}'`
# check from which site this subject came
grep $sub *subjects.txt
@ tr1_dsets++
endif
end
echo ""
echo "Found $tr1_dsets with a TR of 1"

Any update on the missing slice timing information? Also, info about eyes opened/closed would be useful.

Thanks,
Lisa

Lisa,

Sorry for the delays (we have been a bit tied down - joys of grant-writing season :) ). We will do our best to gather information concerning slice timing correction from those who have not provided as of yet and post whatever we have by mid-next week. The same is true for handedness. As for eyes open/eyes closed - an excellent thing to look at...will poll them for that as well.

Best,
Mike

Please see news for updates on slice timing correction, scan condition (eyes open vs. closed) and handedness information.

Great! Thanks for your efforts in getting these info. The slice timing correction should be applied to the original acquisition orientation (axial, sagittal, first slice = bottom or top, left or right). Now all the volumes have been reoriented to RPI. How to trace such information from the nifti file? Thank you!

Dear Yunxia,

You bring up some very relevant issues. I will take a quick stab at addressing them (others please chime in/correct me as desired):

1) The images were all put into a uniform orientation to facilitate management of an otherwise unwieldy data-set (these came to us in many forms). It is important to note that reorientation did not involve any resampling or reslicing of the data that would alter the relationship between slices. If my memory serves me correct, none of the datasets were coronal or sagittal acquisitions (you can verify this by looking at each site and seeing that the x and y directions have the highest resolutions). The specific AFNI commands used for reorienting the data were "3drefit -deoblique", followed by "3dresample -orient RPI". Unfortunately, the data-preparation process knocks out the slice-timing info from the headers - as such, this info is not reliable in the headers for files on the site, though you can find the info in the release table under docs.

2) In FSL, slice order information is solely specified in the command (i.e., the NIFTI header is not used) - you can easily specify there. If AFNI, my impression is that 3dtshift does have a -tpattern option that you can use to force the order from the command line.

I hope that helps.

Best,
Mike

Hello all and many thanks for providing this huge collection of Datasets. In the newly published Doc-File slice-timing information specifies the direction (ascending, descending) only for sequential acquisitions but not for interleaved ones. How can I get the information if interleaved acquisition started at top or bottom (presuming axial acquisition)?
Best regards,
Michel

Hi All,

we updated the release table (see under Docs) to include the most up to date information including slice acquisition order (as per Michel's request). We are still missing information for a few sites, but hope to get those blanks filled in soon.

Thanks for you comments and questions! Keep'em coming!
Maarten

Be sure to check out the site - slice timing info is now updated and, more datasets have arrived - more to come soon! Many thanks to Maarten Mennes for all the hard work.

Best,
Mike

Hi all,

Still one thing about slice timing. For the slice order, our assumption is: for an odd number of slice locations the odds are collected first and for an even number of slice locations the evens are collected first. For instance, for a 5 slice experiment - the order is 1,3,5,2,4, but for a 6 slice experiment - the order is 2, 4, 6, 1, 3, 5. So, I wonder if all the data sets meet this assumption or each has different assumption of order?

Thanks,
Sheng

Hi Sheng,

thanks for your comment and apologies for the late reply, we have been on the road for the last week. We will look into that issue and report back later.

Sorry, I can't be more helpful now,
Maarten

Hello,

I was wondering if I could get an update on slice acquisition details for "Cambridge_Buckner" In the latest excel file, they have specified it as 'interleaved' but not whether ascending/descending.

Thanks,
Alok

Alok,

Sorry for the delay. We verified with Randy Buckner that the data acquisition was interleaved, ascending.

Best,
Mike

Originally posted by Alok Deshpande:

Thanks Mike!

-Alok