TotalReadoutTime inconsistent

[aalbajar]

Dear experts,

I am analysing DTI data, which I converted using MRICROGL . I am trying to find my readout time and I found the following problem:

1. According to my MRI technician, my readout time equals (48-1)*0.744= 34.968 so 0.035 in seconds (since there are 48 echoes and 0.744ms echo spacing in our acquisition).

Nevertheless, when I check the generated .json file when using MRICROGL, it says "TotalReadoutTime": 0.20094.
Which readout-time should I use then for topup and why are they different?

2. Also, this "TotalReadoutTime" seems to be slightly different between participants, is this normal?

Thank you in advance,

Ariadna

[neurolabusc]

@aalbajar can you post the json file? Can you confirm you are using dcm2niix version 1.0.20190410 which comes with the current release of MRIcroGL? @mharms validated the "TotalReadout" time for a huge variation of parameters with images shared in the dcm_qa repository with each new build of dcm2niix tested against this to check for regressions. The Excel spreadsheet notes how the readout time expected by FSL may different from actual readout time (e.g. both SENSE/GRAPPA and Partial Fourier influence actual readout time, but the latter does not reduce the effective readout time). This is discussed in issue 130. In brief, the JSON file follows the BIDS definition of readout time: TotalReadoutTime: This is actually the “effective” total readout time , defined as the readout duration, specified in seconds, that would have generated data with the given level of distortion. It is NOT the actual, physical duration of the readout train.

A value of 200ms sounds very long for an EPI image. If you are using the current version of dcm2niix, you would need to send me a sample (e.g. send a dropbox link to the email address in my avatar) for further advice. I would not expect readout time to vary between different individuals, but some DICOM tags do show odd rounding errors that might explain this.

Further, I want to emphasize that "TotalReadoutTime" only influences the calibrated images FSL creates for review, and it does not influence the resulting warped images that are used for subsequent stages. Most users ignore the calibrated images entirely, so this parameter generally has no influence.

[aalbajar]

Dear @neurolabusc,
Thank you for your answer.
Here's the json file:

"Modality": "MR",
"MagneticFieldStrength": 3,
"Manufacturer": "GE",
"ManufacturersModelName": "DISCOVERY_MR750w",
"InstitutionName": "UZ",
"DeviceSerialNumber": "000000220078MR01",
"StationName": "GEHCGEHC",
"PatientPosition": "HFS",
"SoftwareVersions": "25_LX_MR_Software_release:DV25.0_R01_1451.a",
"MRAcquisitionType": "2D",
"SeriesDescription": "DTI_64DIR_b3000",
"ProtocolName": "DTI_64DIR_b3000",
"ScanningSequence": "EP_SE",
"SequenceVariant": "NONE",
"ScanOptions": "EDR_GEMS_EPI_GEMS_ACC_GEMS_PFF",
"ImageType": ["ORIGINAL", "PRIMARY", "OTHER"],
"SeriesNumber": 10,
"AcquisitionTime": "18:39:15.000000",
"AcquisitionNumber": 1,
"SliceThickness": 4,
"SpacingBetweenSlices": 4.4,
"SAR": 0.0913438,
"EchoTime": 0.1174,
"RepetitionTime": 10,
"FlipAngle": 90,
"PercentPhaseFOV": 100,
"AcquisitionMatrixPE": 128,
"ReconMatrixPE": 256,
"EffectiveEchoSpacing": 0.000788,
"TotalReadoutTime": 0.20094,
"PixelBandwidth": 1953.12,
"PhaseEncodingAxis": "i",
"ImageOrientationPatientDICOM": [
0.985319,
-0.163153,
0.050274,
0.170064,
0.963837,
-0.205175 ],
"InPlanePhaseEncodingDirectionDICOM": "ROW",
"ConversionSoftware": "dcm2niix",
"ConversionSoftwareVersion": "v1.0.20180622 (JP2:OpenJPEG) GCC6.1.0"
}
I will send you one sample in Dropbox.

Thanks again,

Ariadna

[neurolabusc]

I believe the critical lines are

"AcquisitionMatrixPE": 128,
"ReconMatrixPE": 256,

The data was acquired with 128 lines in the phase encoding direction, but interpolated to 256 lines. I think if you upgrade to a modern version of dcm2niix it will use the acquired matrix rather than the interpolated matrix. Can you explain how this was acquired with 48 echoes? Assuming 5/8 partial Fourier there would be 80 steps (though again, FSL ignores this). Does this use in-plane acceleration (SENSE/GRAPPA for Siemens, but ASSET in GE terminology)? I do not know how to detect ASSET from a GE scanner, and have no hardware to investigate this. If you can explain how to detect this, I could upgrade dcm2niix. Regardless, TotalReadoutTime is a calibration value that does not influence subsequent steps of image processing.

As an aside, I would urge all MRI users from avoiding saving interpolated data from the console. The resulting files add no new information, often remove high frequencies, quadruple disk space, always slow down subsequent processing steps and can actually impair subsequent processing (e.g. de-noising and de-Gibbs).

[aalbajar]

Dear Sir,

I was using a previous version of MRIcroGL. Here is the json file generated with the latest MRIcroGL version:
{
"Modality": "MR",
"MagneticFieldStrength": 3,
"ImagingFrequency": 127.766,
"Manufacturer": "GE",
"ManufacturersModelName": "DISCOVERY_MR750w",
"InstitutionName": "UZ_Brussel",
"DeviceSerialNumber": "000000220078MR01",
"StationName": "GEHCGEHC",
"PatientPosition": "HFS",
"SoftwareVersions": "25_LX_MR_Software_release:DV25.0_R01_1451.a",
"MRAcquisitionType": "2D",
"SeriesDescription": "DTI_64DIR_b3000",
"ProtocolName": "DTI_64DIR_b3000",
"ScanningSequence": "EP_SE",
"SequenceVariant": "NONE",
"ScanOptions": "EDR_GEMS_EPI_GEMS_ACC_GEMS_PFF",
"ImageType": ["ORIGINAL", "PRIMARY", "OTHER"],
"SeriesNumber": 10,
"AcquisitionTime": "18:39:15.000000",
"AcquisitionNumber": 1,
"SliceThickness": 4,
"SpacingBetweenSlices": 4.4,
"SAR": 0.0913438,
"EchoTime": 0.1174,
"RepetitionTime": 10,
"FlipAngle": 90,
"PhaseEncodingPolarityGE": "Flipped",
"CoilString": "Head_24",
"PercentPhaseFOV": 100,
"AcquisitionMatrixPE": 128,
"ReconMatrixPE": 256,
"EffectiveEchoSpacing": 0.000788,
"TotalReadoutTime": 0.20094,
"PixelBandwidth": 1953.12,
"PhaseEncodingDirection": "i-",
"ImageOrientationPatientDICOM": [
0.985319,
-0.163153,
0.050274,
0.170064,
0.963837,
-0.205175 ],
"InPlanePhaseEncodingDirectionDICOM": "ROW",
"ConversionSoftware": "dcm2niix",
"ConversionSoftwareVersion": "v1.0.20190410 (JP2:OpenJPEG) (JP-LS:CharLS) Clang10.0.0"
}

[neurolabusc]

I am closing this issue. Comments in the dcm2niix code (which I think @mharms added) explicitly note this 'TotalReadoutTime' should be 'based on the reconstructed matrix in the PE direction'. Further, the TOPUP guide states:

If your readout time is identical for all acquisitions you don't necessarily have to specify a valid value in this column (you can e.g. just set it to 1), but if you do specify correct values the estimated field will be correctly scaled in Hz, which may be a useful sanity check. Also note that this value corresponds to the time you would have had had you collected all k-space lines. I.e. let us say you collect a 96x96 matrix with 1ms dwell-time (time between centres of consecutive echoes) and let us further say that you have opted for partial k-space (in order to reduce the echo time), collecting only 64 echoes. In this case the level of distortion will be identical to what it would have been had you collected all 96 echoes, and you should put 0.095 in the fourth column.

[mharms]

About all I can add is that the value for TotalReadoutTime is entirely defined by the following two "simple" equations in the context of Siemens data ( see #130 (comment) )

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

from which you can see that TotalReadoutTime is effectively just 1/BWPPPE (bandwidth-per-pixel-phase-encode). So, it all boils down to how the Siemens equivalent of BWPPPE is either extracted from the DICOMs, or computed from other parameters within dcm2niix for GE DICOMs.

To my knowledge, the GE calculations/values have not been validated for a wide range of acquisition manipulations as we did for Siemens with #130, and which @neurolabusc coded into the dcm_qa repository -- although see the efforts of @mick-d (#163) and the GE specific notes here.

As @neurolabusc notes, a "correct" value for TotalReadoutTime is only important in the context of FSL's topup if you need/want calibrated field maps, OR if for some reason your two acquisitions with differing polarities have differing TotalReadoutTimes.