I am currently using multiband sequences (from CMRR) without GRAPPA (iPAT), but with LeakBlock (or Split-Slice GRAPPA) on.
My question regards the effective echo spacing (EES) calculation - does the LeakBlock option affect the calculation as GRAPPA does?
From the output .json of dcm2niix, I see that the EES is slightly adjusted when compared to the original. The formula used is Effective Echo Spacing (s) = 1/(BandwidthPerPixelPhaseEncode * MatrixSizePhase)
I understand that Siemens incorporates info regarding in-plane acceleration in the ‘BandwidthPerPixelPhaseEncode’, so I am just checking if no further adjustments are needed due to the LeakBlock (aka Split-Slice GRAPPA) option.
The FSL definition of Effective Echo Spacing and Total Readout Time is unintuitive, as it corresponds to the amount of distortion if the image, not the actual readout time. Therefore, moving from a full Fourier to 5/8 partial Fourier setting reduces the actual Total Readout Time, but does not change the image distortion, so changing this parameter does not impact FSL’s effective values. On the other hand, in-plane acceleration using GRAPPA or SENSE also reduces the number of readout lines, but dramatically reduces the distortion. Therefore, adjusting in-plane acceleration does impact FSL’s value.
The dcm2niix formula for computing effective echo spacing for Siemens sequences was refined and validated by Michael Harms. The validation dataset he acquired is available here - looking at the included Excel spreadsheet you can see the exhaustive work he did. He examined the calibrated field maps to confirm the formula. His tests used the CMMR sequences (this was before product sequences existed with these features). Every commit of dcm2niix source code is tested to ensure it generates the same results on that dataset.
Therefore, for Siemens data from VA-VE systems, I am confident in the dcm2niix calculations for EES. DICOM images from other manufacturers (Philips and GE) do not provide sufficient information to determine these values. Siemens XA systems (Sola, Vida) should provide sufficient information once upgraded with XA13, but remain unvalidated. For readers with any of these systems, you should lobby your Research Collaboration Managers to provide this information. dcm2niix only populates the fields of the BIDS sidecar if we are confident in our results. The good news is that if your readout time is identical for all acquisitions you don’t necessarily have to specify a valid value. Since this is the typical case for research sequences, this is typically not a show stopper.
The LeakBlock only changes how the slices are separated during reconstruction, not the length of the actual readout or the amount of distortion in the image. Therefore, it is irrelevant for the calculation of the EffectiveEchoSpacing and TotalReadoutTime.