Hi,
I agree that you probably shouldn’t trust the divided-by-ten results, though as Matt said, it is strange that you would see any siginificant changes at all if your timings (before the division) are correct.
Just to add to Matt’s response: If you call fugue directly, it assumes that the EPI and fieldmap volumes are in the same voxel space. I hadn’t thought of this first time around, but from the commands you mentioned it seems that the fieldmaps have not been registered or resampled. You can either:
- Use flirt to register the magnitude image of the fieldmap acquisition to your EPI data and then apply that transformation to the fieldmap
- Use flirt to resample the fieldmap to the EPI voxel grid using ‘flirt -in fmap_rads -ref EPI -out fmap_rads_on_EPI -applyxfm -usesqform’. This assumes that there was little subject motion between the two acquisitions.
I am not sure how registration issues would explain the results you are describing though, but it is a bit hard to tell without seeing the images.
In any case, if these are fMRI data that you will be analysing using FEAT, it is probably a good idea to use FEAT’s integrated fieldmap options, as those are much more user friendly and better optimised.
Cheers,
Eelke
> On 28 Jul 2015, at 22:42, Matt Glasser <[log in to unmask]> wrote:
>
> The larger the number, the higher the ³scaling² on the distortion
> correction. Typical dwell time/echo spacings are on the order of 0.## ms
> or 0.000## s. I would be a bit skeptical of results where you simply
> divided by 10 a number in the normal echo spacing range. That would
> suggest that you weren¹t doing much distortion correction at all. You¹ll
> need to be sure you are distinguishing between signal loss in your images
> and actual geometric distortions (i.e. a piece of anatomy that is in a
> different place in the EPI than it is in the T1w image after a rigid 6 dof
> registration. To extract the dwell time directly from the DICOMs, you can
> use this formula:
>
> Dwelltime = 1/(BandwidthPerPixelPhaseEncode * # of phase encoding
> samples): DICOM field (0019,1028) = BandwidthPerPixelPhaseEncode, DICOM
> field (0051,100b) AcquisitionMatrixText first value (# of phase encoding
> samples). On Siemens, iPAT/GRAPPA factors have already been accounted for.
>
>
> You¹ll also want to test that if you reverse the phase encoding direction,
> that you get 2x the distortion one way and corrected distortion the other
> way. And you¹ll want to make sure your field map coming out of
> fsl_prepare_fieldmap looks reasonable.
>
> Peace,
>
> Matt.
>
> On 7/28/15, 4:12 PM, "FSL - FMRIB's Software Library on behalf of Allison
> Letkiewicz" <[log in to unmask] on behalf of
> [log in to unmask]> wrote:
>
>> Yes - used ipat..thank you. I divided the dwell time by 2
>> (0.0006/2=0.0003), but the output is still somewhat distorted.
>>
>> The dwell time divided by a factor of 10 led to results that look
>> distortion corrected...I am just not sure whether to trust them given
>> that I am uncetain what dwell time to use!
|