Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect slice times for Siemens Vida XA11 #303

Closed
neurolabusc opened this issue Jun 27, 2019 · 0 comments

Comments

Projects
None yet
1 participant
@neurolabusc
Copy link
Collaborator

commented Jun 27, 2019

This reflects a error in some Siemens XA11 DICOM multi-band images. Perhaps future versions of dcm2niix can include a kludge to work around this. For the moment, Vida users should carefully inspect the slice times recorded in BIDS JSON files.

Consider a diffusion EPI sequence with multi-band acceleration factor 2, 80 slices per volume and a TR of 5.8sec. The FrameAcquisitionDateTime (0018,9074) values are correct, with a range of 5.7sec with forty unique values. However, TimeAfterStart (0021,1104) is incorrect, with 80 unique values evenly spaced from 0..9.15sec (perhaps times if acquisition had been single band).

The current version of dcm2niix ignores the correct 0018,9074 and instead relies on the incorrect 0021,1104. The reason for this is that 0018,9074 was scrambled by XA10 if the user selected de-identification (as 0018,9074 includes the time of time, while 0021,1104 is only relative to the start of the sequence).

I will attempt to get a shareable dataset. Note that the user reported this problem for diffusion multi-band images, but fMRI data from the same system included the correct 0021,1104.

Possible solutions:

  • Use 0018,9074 to determine slice time. Weakness: would generate garbage on de-identified data. Perhaps Siemens can provide a method to detect if their de-identification has been employed. However, this approach would still fail if a user decided to remove time-of-day tags with an anonymization program.
  • One could fall back to 0018,9074 if 0021,1104 exceeds the TR, but this could fail for sparse designs.
  • One could fall back to 0018,9074 if 0021,1009 reports a multi-band acquisition but their 0021,1104 has no repeats. This seems the most reliable solution, but would require the most code and make the dcm2niix source code even more cryptic.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.