SliceTiming info for muxepi sequence on GE DV26.0_R05

[mharms]

I read the following regarding Slice Timing on GE
https://github.com/rordenlab/dcm2niix/tree/master/GE
and I'm reporting the following in case it represents a bug in the SliceTiming calculation.

Using the ABCD muxepi sequence, on an acquisition with TR=900 ms, 60 slices and MB=6 (i.e., an even number of "shots"), I'm getting the following SliceTiming info using the latest version (v1.0.20211006):

"SliceTiming": [
0,
0.490909,
0.0818182,
0.572727,
0.163636,
0.654545,
0.245455,
0.736364,
0.327273,
0.818182,
0.409091,
0,
0.490909,
0.0818182,
0.572727,
... [REPEAT PATTERN of 11 unique values]
0.818182,
0.409091,
0,
0.490909,
0.0818182,
0.572727,
0.163636 ],

The oddity is that while I don't know what scheme was implemented for an even number of shots (indeed, that is why I was checking the SliceTiming field, to find out), it consists of repeating blocks of 11 different times, instead of the expected 10 different times. And then correspondingly, it ends with an incomplete block of times relative to what one would expect for an MB acquisition (although there are the expected 60 total entries).

I'm not sure if these ST values are extracted directly from the DICOMs, or if they are derived by some calculation. It looks to me like the values are perhaps derived from a calculation, but one which is assuming 11 shots instead 10.

Relatedly, the json is reporting the correct MB factor of 6, but (0043,10b6) is empty, so where/how is the MB factor obtained as an alternative if that DICOM field is empty?

(0043,10b6) LO [0\0\0\\] # 10, 7 Unknown Tag & Data

[neurolabusc]

@mr-jaemin may want to comment. If you have a GE research agreement, I would suggest you request the document Slice Timing Information for fMRI by Brice Fernandez. In addition, you may want to look at the C code here. I believe the issue is that the user specified 60 slices but a multi band of 6. Note that 60 divided by 6 is an even number, hence this is an inherently unbalanced scan. See Figure 3 of Barth et al. as well as Ben Inglis' notes here. In this situation, the GE scanner resorts to an unusual pattern to attempt to address this issue. The compensation applied depends on the GE software version (with a change applied to 27.0 R3).

For future acquisitions, make sure that the number of slices divided by the multi band factor is an even number.

[mharms]

The CMRR sequence does something sensible in the situation of an even number of shots, and I assumed that the GE version would as well. (The issue with acquiring an even number of shots is overblown, IMO).

So, you're saying that the values aren't empirically stored in the DICOMs, but you had access to information from GE itself that provided code that describes how they handled the slice timing and MB implementation for a variety of MB factors and differing number of shots, as a function of software version? In other words, I can trust that these SliceTiming values are an accurate reflection of how the MB was actually implemented and acquired?

[mr-jaemin]

Yes, you (@mharms ) are correct. We took an approach to calculate slice timing information based on scan parameters extracted from DICOM. This is because we (GE) write slice timing information in DICOM accurately from 28 or later release. To support all GE fMRI including earlier software release (DV26 included), we took this approach. As Chris shared the link, we make our validation data available as well as the C code for testing. Also, if reported information in DICOM (28 or later) is different from calculation, dcm2niix generates warning message.

Regarding MB slice timing, MB excitation (=NSlice/MB_factor) is even number, we add one more excitation (becoming odd number to avoid the issue) for earlier release (pre 27.0_R03) fMRI (epi and epiRT family) For 27.0_R03 or later release fMRI, the order of the two last excitation is simply inverted (without adding one more excitation).

Please let me know if you have any question or are interested in the document Slice Timing Information for fMRI by our GE scientist Brice.

[mharms]

@mr-jaemin
Per this https://github.com/neurolabusc/dcm_qa_ge, the validation data is all based on DV28. So, I guess my question is how confident are you that the values derived for SliceTiming for DV26 are accurate?

How is the multiband factor determined if (0043,10b6) is empty? (See my example above).

[neurolabusc]

@mharms dcm2niix can determine this by decoding the geProtocolBlock() (0025,101B). This block zlib-compressed.

[mr-jaemin]

@mharms Short Answer: I am very confident for DV26. In general, dcm2niix generates SliceTiming when we are confident after testing/verification. If not, dcm2niix will NOT generate SliceTiming and instead print out a warning message.

Long answer:
Currently, dcm2niix generates SliceTiming for GE fMRI (not Diffusion yet)

1. With non-HyperBand, ALL software version
2. With HyperBand>1, 26 or later software version.

If mb>1 & version < 26, dcm2niix generate a warning message "Unable to determine slice times for early GE HyperBand" because early GE HyperBand prototype used an offline matlab reconstruction.

Regarding the MB factor, for older software release, this information is stored in the Protocol Data Block (0025, 101B) only and for newer software release, the MB factor is stored in both the Protocol Data Block (0025, 101b) and (0043,10b6):
(0025, 101b) Protocol Data Block contains MBACCEL "2"
(0043,10B6) Multiband Parameters as described in Image Acceleration

In case of missing the Protocol Data Block, dcm2niix print the warning message "Unable to determine GE Slice timing, no Protocol Data Block GE (0025,101B)"

Regarding DV26 MB dataset, we tested/validated the slice timing since GE didn't report slice timing information in DICOM for DV26:

• epi and epiRT offer CV "debug_order" which print data act order table on host
• Confirmed the slice order (from DV26) with dcm2niix's implementaion in various cases
  In fact, dcm2niix initially generated a warning message (Warning message for early GE HyperBand #545) and then removed the warning message after testing (Remove warning for early GE HyperBand dataset after validation #548)

Additionally, we reviewed our PSD changes since DV26 and identified the changes related to how to handle the case with MB excitation = even from 27.0_R03. Beside this, we didn't any changes related to our HyberBand, which reassured that our dcm2niix implementation is accurate

Overall, we clearly defined the scope (see above) and tested/validated them before new dcm2niix release. So, I am confident if you see SliceTiming without any warning message from dcm2niix.

[neurolabusc]

Thanks @mr-jaemin for the comprehensive answer. I am closing the issue.