On 19/11/07 17:09, "Carlos Faraco" <[log in to unmask]> wrote:
> Pablo and Dave,
>
> Thank you both for your replies.
>
> I do have a few more questions for Dave though.
>
>
>> The fast GRE sequences acquire a single line of k-space per echo, but you
>> have less control over TR/TE than the standard GRE sequences. EPI gives
>> distorted fieldmaps.
>
> So you are saying it is OK to use Fast GRE, since you only acquire one line
> per echo?
It's probably still better to use the GRE rather than fast GRE, since you
have more control over the acquisition parameters. TR depends on the
bandwidth, and (if I remember correctly) you have a limited choice of echo
times.
>
>
>> 3) Most likely, but will need a bit of explanation. You've acquired your
>> field map images using a multi-channel receive coil, probably the 8-channel
>> head coil. On GE scanners, when images from all the coils in the array are
>> being combined (with ASSET off) it calculates the square root of the sum of
>> squares for each coil. This even happens when you output real and imaginary
>> parts. I tend to output real and imaginary so I'm not sure what happens to
>> the phase, presumably it either calculates the square root of the sum of
>> squares for each coil, or it calculates the phase from the already combined
>> real & imaginary images. In either case this is invariably not what you
>> want!
>
> You are correct, I did use an 8-channel head coil, I should have mentioned
> that. After writing the first message, I tried what the GE engineer
> suggested and set CV opphasset_factor = 1 (engineer had said asset_factor,
> but we are using software version 14.0_M4) after having chosen ASSET. This
> gave me coil combined phase images that were correctly scaled to -1000pi ->
> 1000pi. I guess this is accomplishing the same result as saveinter = 1 w/out
> the separate images from each coil.
I'll have to try that, and see if it gives the same result. Disc space might
be cheap, but there's no point wasting it if there's an alternative!
>
>> There are two ways to get around the problem. i) on the scan interface
>> change to the body coil for your fieldmap. ii) after you've hit download on
>> the scan interface, but before scanning, change the CV saveinter to 1. You
>> will then get the separate images from each coil, plus the coil-combined
>> images. For example, if you want magnitude + phase using the 8-channel coil,
>> you'll get a total of 18 [2x(8+1)] images per echo-time per slice. You can
>> then calculate the (wrapped) fieldmap using the method described in
>> Bernstein et al, Magn Reson Med 32, 330-334, 1994.
>
> I am unable to access the article, and would have to order it from the
> library. However, does this article describe how to use the combined image
> to get the fieldmap, or how to use the separate coil images?
The article is about how to do phase contrast imaging with array receivers.
The phase difference between (complex) images acquired at two echo times is:
Delta_phi = arg[sum over k of(Z1_k x Z2_k*)/sigma_k^2]
Where Z1_k is the complex image at one echo time for coil k, and Z2_k is the
complex image for coil k at the other echo time. * denotes taking the
complex conjugate, and sigma_k is a coil specific noise figure, which can be
measured, but is often assumed to be equal for all images when not doing
parallel imaging. Taking the complex conjugate ensure the phase difference
is correctly weighted.
>
>> The SNR in the field maps
>> will be much better than using the body coil, with the only drawback being
>> increased storage space, but then disc space is cheap.
>
> I have been told that a fieldmap does not require a high SNR, is this
> correct? If it is, then it seems much simpler to just use the body coil. =]
The noise on our fieldmaps (of a phantom) has an SD of around 4 rad/s with
the body coil, and around 1 rad/s with the array coil. If I can get better
SNR for little other penalty, then I'll use it, but FSL's fugue does have
smoothing options.
>
>> In both cases (i & ii) the phase images should be correctly scaled to
>> -1000pi -> + 1000pi. Personally, I prefer to output the real & imaginary
>> parts, then calculate the phase with the atan2 function.
>>
>
> Are you saying that when using the real and imaginary images you do not have
> to use the method described in Bernstein, et al.? Just use the atan2
> function (not familiar with it) in FSL?
Sorry, I was thinking of the C maths library. It's used to ensure the angle
is in the correct quandrant, since atan(x) just returns a number over a
range of pi, nit 2pi.
>
> Thanks again!!! We have been struggling with this for a while and now it
> seems as if we've almost got it!
|