Calculation of TotalReadoutTime

[mharms]

The reported value for TotalReadoutTime doesn’t match what I’d expect in the case of partial Fourier.
i.e, the BIDS spec defines the TotalReadoutTime calculation via these two websites:

https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/topup/Faq#How_do_I_know_what_phase-encode_vectors_to_put_into_my_--datain_text_file.3F

https://lcni.uoregon.edu/kb-articles/kb-0003

The first of those pages isn't explicit about how “Echo spacing” and “EPI factor” are defined, but the description of readout time on this other (FSL) page
https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/topup/TopupUsersGuide#datain
makes clear that the value should correspond to the total time “you would have had had you collected all k-space lines”.

That’s consistent with the definition on the 2nd (Oregon) web page.

However, from what I can tell dcm2niix appears to be computing the TotalReadoutTime as the Effective Echo Spacing times the number of acquired k-space lines (rather than the number of reconstructed lines).

[neurolabusc]

This is an extension of issue 98. It is important to note that If your readout time is identical for all acquisitions you don't necessarily have to specify a valid value. However, your comment is based on the fact that partial Fourier does not reduce distortion, while in-plane acceleration, e.g. iPAT, SENSE, GRAPPA does. This is unfortunate, as we can therefore not use the true echo train length (0018,0091, which takes into account both pF and iPAT) or total number of phase encoding lines. The latest code should determine the correct solution, though there might be tiny errors due to rounding of phase encoding lines divided by iPAT factor.

The latest code gives the following results (which look correct) for the validation dataset, where both DICOM and protocol PDFs are available for others to validate my conclusions. The 6 series differ in vendor (Siemens vs CMRR sequence), partial-Fourier (pF), iPAT (r), and echo spacing (es), but all reconstruct to 64 lines:

1. no_PF_no_iPAT Siemens pF=1 r=1 es 0.49ms TotalReadoutTime=0.0308698s (0.49*63)
2. 6_8_PF_no_iPAT Siemens pF=0.875 r=1 es 0.49ms TotalReadoutTime=0308698s (0.49*63)
3. no_PF_2_iPAT Siemens pF=1 r=2 es 0.49ms TotalReadoutTime=0.0151899s (0.49*31)
4. no_PF_no_iPAT CMRR pF=1 r=1 es 0.53ms TotalReadoutTime=0.0.0333901s (0.53*63)
5. 68_PF_no_iPAT CMRR pF=0.875 r=1 es 0.53ms TotalReadoutTime=0.0333901s (0.53*63)
6. no_PF_2_iPAT CMRR pF=1 r=2 es 0.55ms TotalReadoutTime=0.01705s (0.55*31)

I would be grateful if you could validate my solution.

[mharms]

Just wanted to capture a note here to reflect all the work that I did looking into the potential nuances of the "EffectiveEchoSpacing" calculation on Siemens scanners (tested under VE11C). In particular, the "number of phase encoding lines" is impacted by a lot more than just parallel imaging, including also partial fourier, phase oversampling, phase resolution, phase FOV, and interpolation. To jump to the chase, the correct equations appear to be:

EffectiveEchoSpacing = 1/[BWPPPE * ReconMatrixPE]
TotalReadoutTime = EffectiveEchoSpacing * (ReconMatrixPE - 1)

where "correct" was confirmed by collecting AP/PA scans with changes to all these parameters and examining the actual estimated field (in Hz) from 'topup'. Further details of the scans tested and their results are available in the Excel file below.

The wrinkle relative to what was known previously is that the info in the DICOM field (0018, 1310) ("AcquisitionMatrix", from which "PhaseEncodingLines" was derived) does NOT reflect the actual matrix size in the PE direction in the reconstructed image in the case of Phase Resolution < 100% and/or Interpolation. So, prior to the changes that I committed today (a8d21b9), if you happened to use Phase Resolution < 100%, or interpolation, the previous calculation for TotalReadoutTime would not provide an accurate estimate of the 'topup' field in physical units (although this is all typically irrelevant anyway for the manner in which 'topup' is typically applied).

PF_PAT_POS_PFOV_PEres_INTERP_test2_2017.09.22.xlsx