Siemens Incorrect Slice Times (Error in the first DICOM file)

[Jihyuncindyhur]

Hi,

I have been working on converting ABCD DICOM files to NIfTI in BIDs format, and I encountered a problem, which has already been discussed in issue #126 . It seems like it had been solved since 'checkSliceTiming()' was added (I'm not sure it has been changed recently as the negative slice time number issue was reported and fixed about 6 days ago #271). I am using dcm2bids.py, which uses the latest version of dcm2niix, and I still have the same issue that MosaicRefAcqTimes values are retrieved from the first DICOM file containing incorrect slice times. In my case, it usually appears like [0, 86399.6, 0.08, 86399.8, 0.16...]. Starting from the second DICOM file, the values seem fine. I was wondering if you could help me with fixing this cause I have read most of the relevant issues that dealt the same problem, and they said it's already fixed. I really appreciate your help and consideration! Thank you.

[mharms]

Why not use the conversion that ABCD has already done? See my comment on the dangers of trying to do this yourself here:
#245 (comment)

[Jihyuncindyhur]

Hi, thanks so much for your comment and the link. It was really helpful. As you pointed it out, I was worried about missing information especially for GE and Philips scanners, so I ended up choosing data only from Siemens. But the problem I reported here was occurred when I did the conversion with all scanner types included. Would excluding files from GE and Philips correct my issue? Thanks!

[mharms]

I don't know. Give it a try. A key thing to keep in mind is that the ABCD fMRI/dMRI scans were NOT acquired with the CMRR SMS/MB sequences, but rather with the MGH SMS/MB sequences (which are much more closely aligned with the Siemens SMS/MB implementation). So, just because a field generates a proper set of values in the CMRR sequences doesn't necessarily mean that it will in the MGH (ABCD) sequences as well.

[Jihyuncindyhur]

Thanks so much for your comment! That makes a lot more sense. My lab is trying to make a further analysis (e.g. connectivity) on the research that has used the preconverted ABCD data. I think I will still give it a try, but do you know any other converters or ways that I can get proper values in the MGH sequences by chance? Thanks a lot, I really appreciate your help!

[mharms]

You would need to engage with the MGH/ABCD folks regarding the specifics of those DICOMs.

[neurolabusc]

@Jihyuncindyhur issue 271 is closed, but you will need to use the development branch to test this out. It will be added to the next stable release. For Unix systems it is usually pretty easy to build the latest commit of dcm2niix yourself with the following commands:

$ git clone --branch development https://github.com/rordenlab/dcm2niix.git
$ cd dcm2niix/console
$ make
$ ./dcm2niix

You can also compile on Windows, but I usually just go to the Development branch Github page, click the AppVeyor button and get the most recently compiled 'Artifact'

Be aware that I have never acquired MoCo data on our Prisma, and have never validated the result. I simply copied rote the formula provided to me by Siemens.

[Jihyuncindyhur]

Thanks so much for your comment and the command lines! I really appreciate them. I will give it a try with the one in the development branch. Thank you again!

[Jihyuncindyhur]

Hi, it worked well with the development branch! Thanks so much for your help. I just have two more questions to ask if you don't mind. First, even though I've successfully got the interleaved ascending slice order for most of the DICOM files, some have seemingly weird slice orders with the values of [0.5475, 0, 0.39, 0.08, 0.47, 0.235, 0.625, 0.3125, 0.7025, 0.1575]. Is this just an unusual but possible case or an issue? If it's the former, could you advise me on which type of slice order I should select when doing slice time correction? Second, I think I already mentioned that I used dcm2bids.py which embeds dcm2niix. Would there be a way that I can possibly incorporate the development build into the dcm2bids.py module and do the conversion and re-organization at the same time? Or should I wait for the next release? Thanks a lot for your help again! I really appreciate it.

[neurolabusc]

All dcm2niix can do is infer the values reported in the DICOM header. One can easily test the actual slice times with a few seconds of scanning. However, since this is a custom sequence I can not tell you if the error is in the header or if this is how the image was acquired. As a general comment, if the TR is very short the slice time variability is very small, and therefore slice time correction does very little Indeed, one might suggest that for such a short TR including the temporal derivative in your models might be sufficient to account to differences for task-based analyses.

[neurolabusc]

In theory make sure dcm2bids.py calls the most recent version. I do not think there are any issues that would hurt backward compatibility.

[neurolabusc]

Closing as duplicate of 271