The echo spacing in the Siemens PDF does need to be divided by the
ipat/GRAPPA factor. Multi-band has no effect on echo spacing.
Peace,
Matt.
On 3/21/14 11:37 AM, "julia" <[log in to unmask]> wrote:
>Hi Michael,
>
>thanks for the helpful comment.
>Does that mean if I have the two parameters 'Echo Spacing' and
>'Multiband Acceleration Factor' from the Siemens report at hand I don't
>even need the information from the DICOM header (which in not
>implemented in my case either)?
>
>Many thanks,
>Julia
>
>
>On 03/13/2014 03:22 PM, Harms, Michael wrote:
>> To further add to this (and hopefully not add any confusion), the
>>formula
>> that Matt supplied for Siemen's acquisitions:
>> Echo Spacing = 1 / [(0019,1028) * (0051,100b component #1)]
>> where
>> 0019 1028: BandwidthPerPixelPhaseEncode -- BW in PE direction (Hz)
>> and
>> 0051 100b: AcquisitionMatrixText (gives size of *reconstructed* matrix)
>> works regardless of whether GRAPPA is used because both variables are
>> specified in terms of the *reconstructed* image.
>> Note that this is therefore the *effective* echo spacing, which is what
>> you want to use in the FSL tools.
>>
>> The sanity check for all of this for Siemens is simply to compare to the
>> ES that Siemen's reports on the Sequence tab of the protocol, keeping in
>> mind that the ES that Siemen's reports is the *actual* echo spacing
>> (actual time between even and odd echoes), so the ES that is reported on
>> the Sequence tab does not change with iPAT factor.
>>
>> So, if you don't use GRAPPA, the two ES's should simply match.
>> If you use GRAPPA, then you need to divide the ES reported on the
>>Sequence
>> tab by the iPAT factor, and that should then give you the "effective"
>>ES,
>> and match the value returned by the calculation
>> Echo Spacing = 1 / [(0019,1028) * (0051,100b component #1)]
>>
>>
>> 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/13/14 4:03 AM, "Mark Jenkinson" <[log in to unmask]>
>>wrote:
>>
>>> Hi,
>>>
>>> That depends on exactly what is extracted as "# of phase encoding
>>> samples".
>>> If that is equal to the number of voxels in the reconstructed image
>>>along
>>> the phase encoding direction then you need to divide it by the
>>> acceleration factor. If it is equal to the number of k-space lines
>>> acquired in the phase encoding direction, then you do not need to
>>>divide
>>> by the acceleration factor, as this will already be less lines
>>>(assuming
>>> it is telling you about the number of lines that are actually
>>>acquired).
>>>
>>> So I think the answer will depend on the system you are using and the
>>>way
>>> that you are extracting the necessary values.
>>>
>>> All the best,
>>> Mark
>>>
>>>
>>> On 13 Mar 2014, at 08:19, Estrid Jakobsen <[log in to unmask]>
>>> wrote:
>>>
>>>> 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.
>>
>> ________________________________
>> 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.
