Hi all,
I am trying to perform preprocessing on denoised optimally combined data (we have four echoes). When performing unwarping in FSL, echo time needs to be entered. My question is, which echo time should I use when using an optimally combined data from tedana?
Thanks in advance.
Kristina
If you’re going to do unwarping, ideally, it should be done before optimal combination and denoising. The amount of warping should change a bit with each echo, which is why FSL probably wants the echo time. I’m not a regular FSL user, but perhaps you can run unwarping along with the other preprocessing steps before optimal combination.
There is a chance imperfection in the unwarping algorithm might make each echo volume unwarp differently enough to cause problems. Perhaps someone else who has done this can speak up & say whether this concern is real. Otherwise, I’d suggest looking at the unwarped volumes carefully to make sure the separate echo data seem reasonably well aligned.
Non-ideally, the unwarping algorithm is using the echo time to make some assumption on how warped the data are, but at the core, I think it’s still just a nonlinear alignment to a less warped image. In that case, I’m not sure how much the echo time actually matters. Try the average echo time and a few other options to see how much that parameter actually alters the unwarped results.
Hope this is helpful.
Dan
I believe for FSL, the EPI TE is just used for signal loss expectations (though I don’t understand the usage). This is based on comments here: JISCMail - FSL Archives
As for the FEAT GUI, it asks for two things: the Effective Echo Spacing
(which is the equivalent of the dwell time) and the EPI TE (which
is only used to deal with signal loss in Gradient Echo EPI, and so
it doesn’t really matter for Spin Echo diffusion sequences). It is
probably safest to put the TE at a low value (although zero may
cause it to crash, so say 1ms) as then it will have a very minimal
impact. Put the dwell time value in as the Effective Echo Spacing.All the best,
Mark
I would likely use the first echo time as that will be a close approximation the signal content (i.e. lack of dropout) in the optimally combined - but I haven’t rigorously examined this.
EDIT: Found it - the function is sigloss, I didn’t see a handy guide online, but its just a tool to estimate how much signal is lost in the EPI - and where. That is then down weighted in the registration steps. So yes, with optimally combined data, I would likely use the first echo time, as signal dropout in the optimally combined image is more or less equivalent to the image at that TE.
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=fsl;51436154.06
Hi Andreas,
You can use the utility sigloss to generate an estimation of the
signal loss at each voxel from a fieldmap. I then generally threshold
this map at about 0.9 to generate a conservative cost function
weighting mask.That is:
… get the original fieldmap (via prelude or other means) …
… do the alignment of the fmap with the epi (via the warped fmap) …
(this involves both fugue and flirt)
… apply fugue to make epi_unwarped, then …sigloss -i fmap2epi -s fmap_sloss -m fmap_bet_mask --te=0.030
avwmaths fmap_sloss -thr 0.9 fmap_sloss_weight
flirt -in epi_unwarped -ref struct -inweight fmap_sloss_weight -omat …Hope that is clear.
Note that this assumes the echo time is 30ms, but obviously put in
the correct time.
I find that this can be quite helpful, especially when there’s a shift in z.I’d advise taking a look at your signal loss estimates and weights the
first time you do it to see that they are sensible and see how conservative
you want/need to be. The threshold value of 0.9 is reasonably conservative.Cheers,
Mark
If that’s all FSL is doing with the echo time, then I think it doesn’t matter much. Either use the first echo or maybe something slightly larger than the first echo. Like I said, I’m not particularly familar with FSL so, if this is just a reference image for an unwarping that’s applied to all volumes, then use a first echo volume as the reference.
@tsalo also reminded me that the tedana group has previously recommended my “non-ideal” ordering from above ( Usage — tedana 0.0.8+0.ge57ea58.dirty documentation ). I still think there may be benefits to undistorting each echo separately, but, as I mentioned, there are non-trivial issues with this that would need to be solved first.
Best
Dan
Thanks both for the input. I was going with the first echo time but I thought it would be good to confirm.
@handwerkerd I am applying distortion correction post-tedana based on the recommended tedana usage.
Cheers,
Kristina
MANAGED BY INCF