Readout_time dwifslpreproc

[mschira]

Hi
I am struggling with choosing the correct readout_time parameter in dwifslpreproc

a) For our Siemens 7T data, the command mrinfo DWI_raw.mif shows a value
TotalReadoutTime = 0.329 is that the value required for dwifslpreproc? Is there a reason one is called readout the other total readout?

b) for our Philips 3T mrconvert does not seem to find a value called TotalReadoutTime, but I have found a way to compute the dwell time and this boils down to echo_spacing * EPFactor

Googling finds several sources telling Total Readout Time (again not readout time, which seems to generic to google…) is calculated as number of echoes * echo_spacing, which would suggest it’s the dwell-time..

Any clarification or pointer where one could read this up?
If dwell-time = TotalReadOutTime = readout-time I could share the information how to extract it from a Philips dicom header. Might be useful? Even potentially automatically importing it?

Best
Mark

[jdtournier]

@mschira

a) For our Siemens 7T data, the command mrinfo DWI_raw.mif shows a value
TotalReadoutTime = 0.329 is that the value required for dwifslpreproc? Is there a reason one is called readout the other total readout?

There’s various definitions around, but what eddy & topup expect is documented here, and refers to the total readout time - the duration of the full echo train.

The simple term ‘readout time’ is clear enough for regular k-space sampling where only one line is acquired at a time. But it’s a bit ill-defined for EPI, since it could correspond to the duration of a single line, or to the full raster. So it’s best to be explicit in EPI, and refer to total readout time or echo train length on the one hand, and inter-echo spacing on the other.

@mschira

b) for our Philips 3T mrconvert does not seem to find a value called TotalReadoutTime, but I have found a way to compute the dwell time and this boils down to echo_spacing * EPFactor

This is not the dwell time, which is normally understood to mean the time between subsequent samples. For the phase-encode direction, the dwell time is the inter-echo spacing. However, that’s not the same as the total readout time, which is indeed dwell time × number of echoes (or equivalently, inter-echo spacing × EPFactor – assuming EPFactor is the number of echoes on a Philips…).

And yes, we’ve not managed to sort out import of this information from Philips DICOMs yet. The main sticking point is not getting the total readout time, but the correct phase-encoding direction – we can tell AP from LR, but not AP from PA (if I recall the details correctly; @rsmith will no doubt correct me if not…).

[grahamwjohnson]

Correct. Phillips DICOMS do not report total readout time or phase encoding direction. They report phase encoding “axis”, so you know it’s either A—>P or P—>A, but cannot differentiate between the two. You must know what was explicitly entered into the settings during acquisition in a field called “fat shift direction” to know the direction of the phase encoding.

[jdtournier]

@grahamwjohnson

You must know what was explicitly entered into the settings during acquisition in a field called “fat shift direction” to know the direction of the phase encoding.

Does this mean that the fat shift direction entry can be used to figure this out? Or is that not recorded in the DICOM headers…?

[grahamwjohnson]

Not recorded in DICOM headers - extremely frustrating.

[mschira]

@jdtournier

This is not the dwell time, which is normally understood to mean the time between subsequent samples. For the phase-encode direction, the dwell time is the inter-echo spacing.

O.K. that is not quite what a Philips document I got is saying.
I quote:

where ETL is the echo train length
and ES refers to echo spacing.

Assuming echo spacing = inter echo time this is still the total readout time, just with a name that’s in disagreement with your terminology.

[rsmith]

a) For our Siemens 7T data, the command mrinfo DWI_raw.mif shows a value
TotalReadoutTime = 0.329 is that the value required for dwifslpreproc? Is there a reason one is called readout the other total readout?

This is simply brevity of the command-line option. I considered calling it “-trt” for Total Readout Time, but decided it was too abstract, so went for -readout_time. But they’re not intended to refer to different things.

Googling finds several sources telling Total Readout Time (again not readout time, which seems to generic to google…) is calculated as number of echoes * echo_spacing, which would suggest it’s the dwell-time..

There’s various definitions around, but what eddy & topup expect is documented here , and refers to the total readout time - the duration of the full echo train.

There is a slight nuance here: FSL’s convention (and what is calculated by MRtrix3 when reading from DICOM) is the time between the centre of the first echo and the centre of the last echo, which is not “the total time taken to perform the EPI readout”.

If dwell-time = TotalReadOutTime = readout-time I could share the information how to extract it from a Philips dicom header. Might be useful? Even potentially automatically importing it?

b) for our Philips 3T mrconvert does not seem to find a value called TotalReadoutTime, but I have found a way to compute the dwell time and this boils down to echo_spacing * EPFactor

If there are DICOM fields that can be used to calculate this parameter that MRtrix3 is not currently reading, then yes, this is something that would be useful to add to the code. Though I’m constantly concerned around this code that calculations need to be correct in the presence of factors such as parallel imaging / segmented EPI…

O.K. that is not quite what a Philips document I got is saying.
Assuming echo spacing = inter echo time this is still the total readout time, just with a name that’s in disagreement with your terminology.

I reckon a large proportion of people in the know would disagree with Philips’ definition of “dwell time” here.

One must also be wary here of parallel imaging; e.g. if only every second line is acquired, then either ES needs to correspond to the time between acquired *k-space lines and ETL needs to correspond to the number of acquired lines, or ES needs to correspond to the effective time in between k-space lines and ETL needs to correspond to the number of k-space lines in the phase encoding direction.

Their calculation also doesn’t include the minus-one effect of wanting the time between the centres of the first and last echoes, which is ultimately the parameter against which the magnitude of geometric distortions scales.

[cgalau]

Hi,

I’m sorry to open this old discussion but I’m facing the same problem as @mschira when trying to process ADNI data. Did you find any solution to sort this issue with “Philips dwell time” information after all this time?

Thanks!
Cristian