Hi Mark,
the smearing of signal mostly from OFC and/or brainstem occurs in the
functional images registered to the individual's structural space with
epi_reg. I did try to optimize the mask size but I cannot completely get
rid of the smearing. I also tried the epi_reg correction with topup derived
fieldmaps and have the same problem in general. Please find two snapshots
of epi_reg outputs attached for an impression on what I mean.
I am implementing these corrections for comparison with another approach.
To make it a fair comparison I am quite eager to get the best possible
solution. I'm happy to share the commands and data if that helps.
Many thanks,
Julia
2014-05-09 21:00 GMT+02:00 Mark Jenkinson <[log in to unmask]>:
> Hi,
>
> thanks again for these clarifications. Do I understand correctly -
> for distortion correction of functional data with topup I could simply use
> the topup output field as it is (or the _fieldcoef?) for input to epireg?
>
>
> You can use the topup output (from --fout) after scaling it to rad/s (by
> multiplying the Hz by 2*pi) as the input fieldmap to epi_reg. The only
> tricky thing might be getting a non-brain-extracted magnitude image. The
> unwarped images from topup are good for the brain-extracted magnitude
> image, but you may need to either edit the epi_reg script to avoid the
> non-brain-extracted registration step, or to register a non-brain-extracted
> image to the space of the topup output to act as a surrogate.
>
> I can only repeat, this detailed support is highly appreciated.
> Best, Julia
>
> PS on the fieldmaps: when I used too small of a mask for preparing the
> fieldmap for my data, epireg started to strongly smear the signal in the
> OFC where the EPI was not covered by the fieldmap. I am just mentioning it,
> because before it sounded to me like it would always be the better option
> to use a smaller mask when in doubt. I don't know whether this is just
> something specific to my data though.
>
>
> Was this smearing in the outputs registered to structural space, or
> after transforming into standard space? It is fairly common to see a bit
> of smearing in standard space, but it isn't common to see in the structural
> space outputs, or the unwarped functionals from epi_reg. However, the mask
> really only needs to be made smaller to avoid noisy voxels in the standard
> fieldmap phase images (which are just at the edge of the brain). So
> normally this doesn't make things so small that there is a problem. There
> is a step inside the processing that also tries to clean up these noisy
> voxels, but we recommend a tight mask to be a little conservative. If you
> are getting bad results then try to run things with a slightly larger mask
> and see if that works better.
>
> All the best,
> Mark
>
>
>
>
> 2014-05-06 8:39 GMT+02:00 Mark Jenkinson <[log in to unmask]>:
>
>> Hi,
>>
>> What I wanted to make clear here was that topup itself was not
>> performing the distortion correction, like it can for diffusion data (since
>> topup cannot be used in this mode for functional data).
>>
>> Although there is the option in the HCP scripts to register the SBRef
>> image directly to the spin echo output from topup, then convert the
>> topup-derived fieldmap into a warpfield and apply this directly to the
>> functional scan, I would still advise people to use flirt (or epi_reg) for
>> the distortion correction in general. This is because the registration of
>> the functional image (SBRef) to the spin echo image will only work
>> accurately if (a) the distortions are exactly matched in the acquisitions,
>> which won't typically be the case, and (b) the signal loss in the
>> functional images does not affect the registration accuracy. For the HCP
>> these two conditions will be met, but others would need to carefully check
>> if it was true for their data before using this method. However, the
>> method of using flirt/epi_reg will work even when these conditions are not
>> met and so I would recommend that as the more robust/reliable method in
>> general.
>>
>> All the best,
>> Mark
>>
>>
>> On 5 May 2014, at 13:58, Matt Glasser <[log in to unmask]> wrote:
>>
>> Hi Mark,
>>
>> In my implementation, the distortion correction is done before flirt
>> BBR. The reason is that the gradient echo SBRef and spin echo image of
>> matching phase are very easy to register to each other rigidly (because
>> they have the same resolution, ,FOV, and distortions). The topup field is
>> output as a FSL warpfield and used the do the correction.
>>
>> Peace,
>>
>> Matt.
>>
>> From: Mark Jenkinson <[log in to unmask]>
>> Reply-To: FSL - FMRIB's Software Library <[log in to unmask]>
>> Date: Monday, May 5, 2014 at 5:46 AM
>> To: <[log in to unmask]>
>> Subject: Re: [FSL] flirt -bbr -fieldmap compared to flirt -bbr /
>> freesurfer bbregister
>>
>> Hi,
>>
>> Just to clarify here - for fMRI scans, topup was used to create a
>> fieldmap which was then used in BBR to do the distortion correction, as
>> opposed to using topup itself to do the distortion correction (as the
>> latter is only possible for diffusion images, not for functional ones).
>>
>> So, in answer to your question about the order of steps, we do not
>> register the fieldmap to the functional image directly. We used epi_reg
>> (in FSL) to register fieldmap to structural and then functional to
>> structural, with the fieldmap correction. This step did the distortion
>> correction. Later on a second BBR step was run with freesurfer, using the
>> distortion corrected images as input, that refined the rigid-body
>> registration between the undistorted functional image and the structural
>> image.
>>
>> All the best,
>> Mark
>>
>>
>> On 2 May 2014, at 14:41, Matt Glasser <[log in to unmask]> wrote:
>>
>> HCP data were corrected with spin echo field maps (phase reversed spin
>> echo images) using topup before running FLIRT BBR and FreeSurfer BBR.
>>
>> Peace,
>>
>> Matt.
>>
>> From: julia <[log in to unmask]>
>> Reply-To: FSL - FMRIB's Software Library <[log in to unmask]>
>> Date: Friday, May 2, 2014 at 4:24 AM
>> To: <[log in to unmask]>
>> Subject: Re: [FSL] flirt -bbr -fieldmap compared to flirt -bbr /
>> freesurfer bbregister
>>
>> Dear Mark, and also Matt before,
>>
>> thank you so much for your detailed explanations which are extremely
>> valuable to me.
>>
>> As a last tiny follow-up: For the HCP data, did you register the fieldmap
>> to the functional data, unwarped and then registered to anatomy? Or did you
>> rather pre-register to anatomy (w/o bbr option?) both the fieldmap and the
>> functional image, unwarped and then finetuned with bbr?
>>
>> Thanks a lot for being so helpful,
>> Julia
>>
>>
>>
>>
>> On 05/02/2014 10:14 AM, Mark Jenkinson wrote:
>>
>> Hi,
>>
>> thank you so much for your comprehensive answer and sorry for not
>> being clear enough on my question about the "magic". I am interested in the
>> additional benefit of using the fieldmap within flirt bbr. Or: what is the
>> difference between the workflow in epi_reg and an alternative workflow
>> where everything is equal apart from the fact that the fieldmap (registered
>> to anatomy) is applied to unwarp the EPI (pre-registered to anatomy with
>> normal flirt like it is done in epi_reg) *before* running flirt bbr
>> (without fieldmap) instead of *simultaneous* unwarping and bbr
>> registration (flirt -bbr -fieldmap). Assuming the transformations would be
>> combined in the end to avoid multiple interpolations.
>>
>>
>> That is a tricky question, although the short answer is probably "not
>> much". The use of bbr in the first step will already register to the
>> structural image, so you are never avoiding that, but running things in the
>> second stage, with an unwarped functional image as input can change things
>> subtly.
>>
>> The long answer is that the main difference will be that the second
>> stage of the non-simultaneous version will need to use an interpolated
>> image as the input image to work with. When we investigated this for the
>> HCP, we ended up using such a strategy with the non-fieldmap bbr step being
>> run by freesurfer, and hence fed with an unwarped (and interpolated) image.
>> When I fed the same image into flirt (as a two-stage process, so replacing
>> the freesurfer bbr with flirt) I found that there was very little
>> difference between the freesurfer and two-stage flirt results (less than
>> comparing to simultaneous flirt). However, because we wanted to use the
>> freesurfer segmentations for the best GM-WM edges, then we just stuck with
>> freesurfer for the second bbr step, although I found that with the same
>> input (surface and unwarped image) there was almost no difference between
>> flirt and freesurfer bbr. The difference between using flirt with the two
>> stages rather than simultaneous is probably about slight smoothing benefits
>> from the unwarping step, which on HCP data matter more than I suspect they
>> do in most other data. You could try this yourself and see. It is likely
>> to be hard to see the differences, and the exact benefit/detriment will
>> probably be highly dependent on the quality of the structural, functional
>> and fieldmap images.
>>
>> Concerning the masking I am a bit confused now. Within epi_reg, if I
>> see it right, the mask that is used in the first fugue step is a
>> multiplication of the binarised magnitude brain image and the binarised
>> fieldmap:
>>
>> $FSLDIR/bin/fslmaths ${fmapmagbrain} -abs -bin
>> ${vout}_fieldmaprads_mask
>> $FSLDIR/bin/fslmaths ${fmaprads} -abs -bin -mul
>> ${vout}_fieldmaprads_mask ${vout}_fieldmaprads_mask
>> $FSLDIR/bin/fugue --loadfmap=${fmaprads}
>> --mask=${vout}_fieldmaprads_mask --unmaskfmap
>> --savefmap=${vout}_fieldmaprads_unmasked --unwarpdir=${fdir}
>>
>> This would always result in a mask which is as small as the fieldmap
>> itself or smaller, right? Where does (or should) the extrapolation happen
>> then? Maybe I don't understand the function of the mask in fugue or am
>> misinterpreting the script?
>>
>>
>> The masking here is done to make sure that only valid fieldmap values
>> are kept within the brain extracted mask. It is usually quite tight and
>> can remove a bit of brain tissue, which is fine as it is better to do that
>> in this context rather than keep in any of the noisy voxels that sit at the
>> brain edge in the fieldmap. So we extrapolate the fieldmap (rad/s) image
>> using fugue (as this always extrapolates internally), and this is
>> explicitly specified via the --unmaskfmap flag (as otherwise the fieldmap
>> would be masked on output). It is important to do it this way to remove
>> these noisy voxels at the brain edge, and because the fieldmap is pretty
>> smooth, extrapolation by a few voxels near the edge is a fairly
>> safe/accurate thing to do.
>>
>> I hope this helps.
>> All the best,
>> Mark
>>
>>
>>
>> Many thanks in advance,
>> Julia
>>
>>
>>
>>
>> On 04/23/2014 08:41 AM, Mark Jenkinson wrote:
>>
>> Dear Julia,
>>
>> I'm not quite sure what this "magic" is that you and Matt are referring
>> to.
>> The process inside the epi_reg script is to register the fieldmap (which
>> is undistorted) to the structural image and then use the fieldmap in
>> structural space when doing the distortion correction and rigid-body
>> registration of the EPI to the structural simultaneously. If you are just
>> using the flirt command line then you will need to get the fieldmap into
>> structural space yourself. However, if you've already applied a fieldmap
>> distortion-correction step prior to flirt then you should not use the
>> fieldmap again (as this would overcorrect) and can just use the bbr option
>> with the 6 dof setting. I wasn't very clear as to your pipeline, so I hope
>> this helps explain what is appropriate for you.
>>
>> As for the masking issue, it is necessary to have a tight mask into the
>> fsl_prepare_fieldmap step in order to exclude noisy voxels that occur at
>> the edge of the brain. However, when applying the fieldmap it should not
>> be masked in this way and does need to be extrapolated. The "too small"
>> hack in the script is not for this extrapolation (as this extrapolation is
>> easily done with fugue) but is instead there to deal with cases where the
>> FOV was cut-off, typically in the through-slice direction, by a much larger
>> factor that goes beyond what the fugue extrapolation was good at dealing
>> with.
>>
>> Finally, to answer Matt's question, I have not added GIFTI input
>> support to FLIRT at this stage.
>>
>> All the best,
>> Mark
>>
>>
>>
>> On 18 Apr 2014, at 17:25, julia <[log in to unmask]> wrote:
>>
>> Thanks again!
>> I would be very interested in the "magic" in flirt bbr when used with a
>> field map.
>>
>> If I may I'd have one more question (possibly related to the magic):
>>
>> It is advised to use a rather small mask for fsl_prepare_fieldmap.
>> However, when I apply such a fieldmap directly in fugue (i.e. after
>> unmasking), smaller maps tend to smear the signal in areas that are not
>> covered by the fieldmap.
>> Is this dealt with by the "new hack for extrapolation if fieldmap is too
>> small" part in the epi_reg script? What confuses me is that there, the
>> dilated fieldmap version is only used inside flirt bbr, not for the later
>> warping (if I read it right).
>>
>> Best regards,
>> Julia
>>
>>
>>
>> On 04/16/2014 05:49 PM, Matt Glasser wrote:
>>
>>
>> 1. FLIRT BBR is a better and more robust initialization than the
>> other FreeSurfer initialization methods (so I actually turn off
>> bbregister’s initialization).
>> 2. I don’t think it is possible to give flirt bbr a GIFTI surface,
>> but perhaps Mark has made this change by now?
>> 3. I’m not sure I follow the goal of the process here, but perhaps
>> Mark does? Mark will have to explain what happens inside flirt bbr when
>> used with a field map, but I think there is some “magic” in it.
>>
>> topup and regular field map corrections appeared very similar to us, but
>> topup’s can be acquired faster and has the advantage I mentioned below in
>> terms of robustness.
>>
>> Peace,
>>
>> Matt.
>>
>> From: Julia Huntenburg <[log in to unmask]>
>> Reply-To: FSL - FMRIB's Software Library <[log in to unmask]>
>> Date: Wednesday, April 16, 2014 at 10:36 AM
>> To: <[log in to unmask]>
>> Subject: Re: [FSL] flirt -bbr -fieldmap compared to flirt -bbr /
>> freesurfer bbregister
>>
>> Thanks a lot, Matt, that is all extremely helpful.
>>
>> Just three quick follow-ups:
>>
>> 1. If freesurfer bbr is more accurate, what would be the advantage of
>> using flirt bbr first instead using freesurfer bbr straight away?
>> 2. If the segmentation is the main difference, would it be reasonable
>> to assume flirt bbr would perform similarly well when fed with a freesurfer
>> segmentation?
>> 3. In case I register both EPI and fieldmap to the anatomy before, then
>> apply the fieldmap and then do another round of registration (unwarped EPI
>> to anat) with bbregister, that would not be different (at least no
>> disadvantage) to performing this last step with flirt -bbr -fieldmap (as in
>> epi_reg)? I.e. there is nothing magical happening inside flirt -bbr when it
>> is provided with a fieldmap?
>>
>> Also the hints on topup correction are very valubale for me as I am
>> currently implementing both methods for distortion correction for my data
>> to compare them.
>>
>> Many thanks again, great help!
>> Julia
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2014-04-16 17:17 GMT+02:00 Matt Glasser <[log in to unmask]>:
>>
>>> FreeSurfer BBR is generally slightly more accurate than FLIRT BBR,
>>> probably because of the much higher quality surface being used (i.e. the
>>> FLIRT BBR makes a quick white matter surface based on a FAST segmentation,
>>> whereas FreeSurfer’s white matter surface is based on a lot more
>>> processing). For HCP Minimal Preprocessing Pipelines where we cared about
>>> getting the alignment right down to submm levels, we used both (FLIRT BBR
>>> first and then FreeSurfer BBR).
>>>
>>> Whether or not it is better to use the field map with FLIRT BBR or
>>> apply it before depends on how good of a field map to EPI registration you
>>> can get outside of FLIRT BBR vs a field map to structural registration (and
>>> EPI to structural registration) inside FLIRT BBR (i.e. epi_reg). Generally
>>> one does a better job inside of FLIRT BBR, but this is not always the case.
>>> Also, it can be harder to debug what is going wrong when the steps are not
>>> separated (is my registration not good because the distortion correction is
>>> not good, or because the EPI to structural registration is not good?).
>>>
>>> I actually prefer using spin echo field maps (phase reversed spin echo
>>> images matched to the gradient echo EPI acquisition) and topup, as these
>>> have the same distortion as the gradient echo EPIs and can be very
>>> precisely registered (EPI to matching spin echo image) without the
>>> complication of using the structural image as an intermediate. Then one
>>> can use BBR on the undistorted EPI image. This keeps each step separate
>>> for debugging and “easy” for the algorithms involved to achieve robustly.
>>>
>>> Peace,
>>>
>>> Matt.
>>>
>>> From: Julia Huntenburg <[log in to unmask]>
>>> Reply-To: FSL - FMRIB's Software Library <[log in to unmask]>
>>> Date: Wednesday, April 16, 2014 at 9:25 AM
>>> To: <[log in to unmask]>
>>> Subject: [FSL] flirt -bbr -fieldmap compared to flirt -bbr / freesurfer
>>> bbregister
>>>
>>> Dear list,
>>>
>>> Concerning the usage of flirt with bbr cost function and a fieldmap I
>>> was wondering if there is any experience on:
>>>
>>> 1. how different it is to use the flirt -fieldmap option as compared to
>>> unwarping with the fieldmap first and using flirt -bbr afterwards?
>>> (-- and related: How exactly is the fieldmap applied in this
>>> implementation?)
>>>
>>> 2. how the FSL bbr implementation compares to freesurfer bbregister?
>>> E.g. if I use the freesurfer segmentation with flirt -bbr, would that give
>>> me similar results as bbregister?
>>>
>>> Any thoughts or experience (even if anecdotal) would be highly
>>> appreciated!
>>> Many thanks,
>>> Julia
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
