Thanks for all the helpful responses. To clarify, does this mean that for a GRAPPA sequence, I should calculate the dwell time as described by Matt and then divide that by the acceleration factor? As in:
Dwelltime = (1/(BandwidthPerPixelPhaseEncode * # of phase encoding samples))/Acceleration factor
Thanks again!
Estrid
****************
Estrid Jakobsen
PhD Student, IMPRS NeuroCom
Department of Neurophysics
Max Planck Research Group Neuroanatomy and Connectivity
Max Planck Institute for Human Cognitive and Brain Sciences, Leipzig
+49 341 9940-2423
----- Original Message -----
From: "Mark Jenkinson" <[log in to unmask]>
To: [log in to unmask]
Sent: Thursday, March 13, 2014 12:32:54 AM
Subject: Re: [FSL] Dwell time calculation for FUGUE
Hi,
Just to clarify for the record:
- The "dwell time" required in FSL is indeed the "effective echo spacing" and for an unaccelerated sequence is equal to the amount of time taken between crossings of the k_y axis (in k-space, where k_x=0). That is, the time between one crossing and the next.
- Partial Fourier does not affect this.
- GRAPPA, or equivalent accelerations that skip lines of k-space, require the echo spacing to be divided by the acceleration factor (hence giving the "effective" echo spacing)
I hope this helps.
All the best,
Mark
On 12 Mar 2014, at 19:37, Joel Bruss <[log in to unmask]>
wrote:
> In this case, yes, but thanks for the caution. I'll switch it on my end to search for "AcquisitionMatrixText" instead.
> On 03/12/2014 02:27 PM, Harms, Michael wrote:
>> Are you sure that the value of the "PhaseEncodingLines" string is the same
>> as the first value of "AcquisitionMatrixText", in instances of GRAPPA,
>> partial Fourier, etc?
>>
>> cheers,
>> -MH
>>
>> --
>> Michael Harms, Ph.D.
>>
>> -----------------------------------------------------------
>> Conte Center for the Neuroscience of Mental Disorders
>> Washington University School of Medicine
>> Department of Psychiatry, Box 8134
>> 660 South Euclid Ave. Tel: 314-747-6173
>> St. Louis, MO 63110 Email: [log in to unmask]
>>
>>
>>
>>
>> On 3/12/14 2:05 PM, "Joel Bruss" <[log in to unmask]> wrote:
>>
>>> Thanks for that, Matt. I'd read something similar before but the DICOM
>>> I have has "Unimplemented" in the 0019,1028 header field. 0051,100b
>>> doesn't exist as well. I had to use the ascii header to grab the same
>>> information:
>>>
>>> dcmPic=`ls *dcm | sort -t. -k 5 -n | head -1 | tail -1`
>>> BWpe=`strings $dcmPic | grep -A1 "BandwidthPerPixelPhaseEncode" | head
>>> -2 | tail -1`
>>> dimpe=`strings $dcmPic | grep -A1 "PhaseEncodingLines" | head -1 | awk
>>> '{print $3}'`
>>> dwellTime=`echo $BWpe $dimpe | awk '{print (1/($1*$2))}'`
>>>
>>> Hope this helps someone else.
>>>
>>> -Joel
>>>
>>> On 03/12/2014 01:58 PM, Matt Glasser wrote:
>>>> For Siemens:
>>>>
>>>> #Echo Spacing or Dwelltime of fMRI image in seconds =
>>>> 1/(BandwidthPerPixelPhaseEncode * # of phase encoding samples): DICOM
>>>> field (0019,1028) = BandwidthPerPixelPhaseEncode, DICOM field
>>>> (0051,100b)
>>>> AcquisitionMatrixText first value (# of phase encoding samples)
>>>>
>>>> I believe this accounts for GRAPPA factors and partial fourier does not
>>>> affect the echo spacing.
>>>>
>>>> Peace,
>>>>
>>>> Matt.
>>>>
>>>> On 3/12/14 1:33 PM, "Estrid Jakobsen" <[log in to unmask]> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I am trying to do fieldmap correction of 7T EPI data using FUGUE, which
>>>>> requires input of a variable, 'dwell time'. If I've understood
>>>>> correctly,
>>>>> this variable actually refers to the 'effective echo spacing' (rather
>>>>> than simply the dwell time listed in the DICOM of the EPI data) but
>>>>> there
>>>>> seem to be several methods to calculate it.
>>>>>
>>>>> 1. DwellTime = (EchoSpacing/GRAPPA)-1
>>>>>
>>>>> 2. DwellTime = EchoSpacing*((MatrixLines*PartialFourier/GRAPPA)-1)
>>>>>
>>>>> Which of these options (if either) is correct for running FUGUE?
>>>>>
>>>>> Many thanks!
>>>>>
>>>>> Estrid
>>
>> ________________________________
>> The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
|