slice timing in BIDS json is in incorrect units

[poldrack]

Slice timing for BIDS should be in seconds, but I get this (in a dataset with TR of 1.16 secs):

  "SliceTiming": [
            0,
            0.6125,
            0.0675,
            0.6825,
            0.135,
            0.75,
            0.205,
            0.8175,
            0.2725,
            0.885,
            0.34,
            0.955,
            0.4075,
            1.0225,
            0.4775,
            1.09,
            0.545,
            6.96,
            7.5725,
            7.0275,
            7.6425,
            7.095,
            7.71,
            7.165,
            7.7775,
            7.2325,
            7.845,
            7.3,
            7.915,
            7.3675,
            7.9825,
            7.4375,
            8.05,
            7.505,
            13.92,
            14.5325,
            13.9875,
            14.6025,
            14.055,
            14.67,
            14.125,
            14.7375,
            14.1925,
            14.805,
            14.26,
            14.875,
            14.3275,
            14.9425,
            14.3975,
            15.01,
            14.465,
            20.88,
            21.4925,
            20.9475,
            21.5625,
            21.015,
            21.63,
            21.085,
            21.6975,
            21.1525,
            21.765,
            21.22,
            21.835,
            21.2875,
            21.9025,
            21.3575,
            21.97,
            21.425  ],

let me know if you'd like me to share the dicoms that were used to generate this.

[neurolabusc]

Yes, please send me a sample. The array "SliceTiming" should be in seconds and the maximum value should always be less than the "RepetitionTime". This is certainly the case with all the Siemens Prisma datasets in our test repository. One thought is that an old release of the CMRR sequences had a bug with recording slice timing that was fixed in 2014. In general, the CMRR sequences are terrific, but images from acquired from a brief period present problems. As I recall, problem was only with the first volume.

[poldrack]

that does indeed sound like the culprit as these were collected using the CMRR sequence in late 2013. will send the dicoms shortly

…

On Thu, Aug 31, 2017 at 7:23 AM, Chris Rorden ***@***.***> wrote: Yes, please send me a sample. The array "SliceTiming" should be in seconds and the maximum value should always be less than the "RepetitionTime". This is certainly the case with all the Siemens Prisma datasets in our test repository <https://github.com/neurolabusc/dcm_qa>. One thought is that an old release of the CMRR sequences had a bug <https://afni.nimh.nih.gov/afni/community/board/read.php?1,145461,145461#msg-145461> with recording slice timing that was fixed in 2014 <CMRR-C2P/MB#29>. In general, the CMRR sequences are terrific, but images from acquired from a brief period present problems. As I recall, problem was only with the first volume. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#126 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1KkOEE-CaSAdMs_htSqC3yBRksUnrJks5sdsH7gaJpZM4PI5Lq> .

-- Russell A. Poldrack Albert Ray Lang Professor of Psychology Professor (by courtesy) of Computer Science Bldg. 420, Jordan Hall Stanford University Stanford, CA 94305 [email protected] http://www.poldracklab.org/

[neurolabusc]

Please try out the latest master source. As I suspected, this was due to a buggy CMRR image. The good news is only the first image is corrupted, so not only is the problem detected, but it should be patched as the new version pulls the correct values from the 2nd volume in the series. Please validate this. The detection and fix uses the new function checkSliceTiming(). To be pedantic, this is an enhancement to rather than a bug with dcm2niix.

[poldrack]

just tested it, looks like problem is solved, thanks!