AFNI Message Board

Dear AFNI users-

We are very pleased to announce that the new AFNI Message Board framework is up! Please join us at:

https://discuss.afni.nimh.nih.gov

Existing user accounts have been migrated, so returning users can login by requesting a password reset. New users can create accounts, as well, through a standard account creation process. Please note that these setup emails might initially go to spam folders (esp. for NIH users!), so please check those locations in the beginning.

The current Message Board discussion threads have been migrated to the new framework. The current Message Board will remain visible, but read-only, for a little while.

Sincerely, AFNI HQ

History of AFNI updates  

Previous Message Next Message
Message List New Topic Print View
|
Mingbo
July 10, 2014 02:28AM
Hello,
I have noticed some problem of getting correct slice timing of multiband fMRI data generated by the custom sequence built by CMRR of University of Minnesota. For reference of their slice timing, here is a link. We use Siemens Trio scanner with 32 channel coil.

The command I used for to3d was like this:
to3d -epan -prefix empty_run.01 -assume_dicom_mosaic -oblique_origin -time:zt 58 274 2000 FROM_IMAGE -anatparent inplane.02+orig. -zpad 1 ...

Running "3dinfo -slice_timing" for the generated empty_run.01+orig gave me output like this:

0.000000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|-0.666000|0.000000


Running it for any specific sub-brick gave me this:
0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|0.000000

But if I run "dicom_hdr -slice_times" for any dicom file other than the first volume, it gives me correct timing that is consistent with what the document (linked above) says. Notice that the document mentioned a bug that the timing stored for the first volume was always wrong (simply speaking, all time stamps stored for odd slices are larger than the actual TR).

So I am not sure if this problem is because to3d reads the slice timing information from the first dicom image and gets confused? If so, can you make it read from the last image?

The forum does not allow me to upload dicom file. If you need sample dicom file please let me know how I can upload.

Thanks!

Mingbo
Reply Quote
RSS
Subject Author Posted

to3d failed to read slice timing information for multiband data

Mingbo July 10, 2014 02:28AM

Re: to3d failed to read slice timing information for multiband data

rick reynolds July 10, 2014 03:21PM

Re: to3d failed to read slice timing information for multiband data

Mingbo July 10, 2014 09:34PM