fmriprep
fmriprep copied to clipboard
nipreps
Multi-echo derivatives
- [x] T2* map (space
boldref?) - [x] All echos, with STC+HMC+SDC applied (new flag)
- [ ] Decompositions
- [ ] _mixing.tsv separate from _desc-confounds_timeseries.tsv
- [ ] _metrics.tsv + json (non-BEP-012)
cc @jbteves @tsalo @eurunuela for verification
- [ ] T2* map (space
boldref?)
The T2* map is the boldref as of #2547, which will be in 21.0.0. I think by BIDS, we should change the suffix to T2starmap in the multi-echo case.
- [ ] All echos, with STC+HMC+SDC applied (new flag)
Let's call this space T2starmap, and we will always want it if individual echos are requested. If that's the case, would we also want the optimal combination in this space, or is it possible that we'd want the OC in T1w or MNI, but not in T2starmap?
Just trying to figure out the branching logic that we're going to need and how many flags will be needed to cover the range of plausible outputs.
The T2* map shouldn't be the boldref since we removed that option in #2109, right?
Do you want to check #2547? I'm not sure if we re-did that or not, but it's definitely what's set to be saved as a _boldref.nii.gz image.
You're right. For posterity, here it is:
https://github.com/nipreps/fmriprep/blob/a02c1c110966fd3f357c222992aa670d234da396/fmriprep/workflows/bold/base.py#L1005-L1008
I'm not sure why that was done. In #2181, we started calculating the final boldref based on the first echo's STC+MCed data (i.e., post-bold_bold_trans_wf), since that echo would have the most brain coverage.
https://github.com/nipreps/fmriprep/blob/5e291b88b72d21599ea70b43f8233a4e26d321d7/fmriprep/workflows/bold/base.py#L574-L575
We stopped using the T2* map because, while it was originally thought to have better contrast (hence the old --t2s-coreg option), it ended up not performing very well. @emdupre does that sound right?
BTW, to respond to your other question:
Let's call this space T2starmap, and we will always want it if individual echos are requested. If that's the case, would we also want the optimal combination in this space, or is it possible that we'd want the OC in T1w or MNI, but not in T2starmap?
I don't think there's a strong reason to have the OC data in the T2starmap/boldref space, since it's (1) easy enough to calculate when you have the echoes, echo times, and T2* map, and (2) tedana doesn't actually allow you to provide the OC data when you're running the classification workflow on an existing mixing matrix, due to (1). So it won't be much use. That said, if it doesn't add many LOC, then I don't see the harm.
Okay, so we should revert the t2star_map -> boldref change and these will be two separate derivatives as well.
Would people just want the raw T2* map or transformed into the --output-space-declared spaces, or both?
Regarding the OC, it's not really a question of LOC, and the harm would be space wasted on an unwanted derivative. So the upshot of my question and your answer is that we shouldn't use --output-spaces T2starmap to decide that we want the cleaned echos since people are unlikely to want all of the consequences of that. Let's assume we'll go with something like --bold-echos.
So let's suppose I have --output-spaces anat --bold-echos, I should get something like:
sub-01/func/sub-01_task-rest_space-anat_boldref.nii.gz
sub-01/func/sub-01_task-rest_space-anat_desc-preproc_bold.nii.gz
sub-01/func/sub-01_task-rest_space-orig_T2starmap.nii.gz
sub-01/func/sub-01_task-rest_echo-1_space-orig_desc-preproc_bold.nii.gz
sub-01/func/sub-01_task-rest_echo-2_space-orig_desc-preproc_bold.nii.gz
sub-01/func/sub-01_task-rest_echo-3_space-orig_desc-preproc_bold.nii.gz
Seem reasonable? (Might need to do something other than orig. I'll check the spec.)
So it looks like we're performing SDC on the optimal combination, rather than on the individual echos prior to T2*-map estimation.
To get STC+HMC+SDC echos, we can either apply the SDC to the echos after the fact (and I guess the T2* map), or we can pass in SDC'd time series to Tedana.
What is the Tedana best practice here?
Would people just want the raw T2* map or transformed into the --output-space-declared spaces, or both?
The main benefit is in running tedana, but it can also be useful for QC. I don't know if that QC needs to be in standard space, but it could help. That said, I don't think it's a big deal if the T2* map is just in boldref space. @handwerkerd do you think a standard space T2* map would be necessary?
The outputs you list seem reasonable, though having the brain mask in orig space would be very helpful.
What is the Tedana best practice here?
We currently recommend using non-SDCed data in tedana, but we don't have any actual tests comparing pre-SDC vs post-SDC. I have been using the SDCed data in my own analyses, because it's easier to take STC+MC+SDCed data, run it through tedana, and then apply the necessary transforms than to grab the data before SDC. If it's easy enough to run tedana within fMRIPrep before SDC, then I'd lean slightly toward that.
So when you get your individual echo derivatives, you would want them STC+HMC but not SDC'd? And similarly, the T2* map should not be SDC'd?
But your optimal combinations should still be SDC'd?
Would you also need the SDC warp (I think we should do this, but it will affect priorities) to be output?
Since I'm not an fMRIprep user, I don't completely follow the specific issue at hand here. If I get the part where you're asking me a question, it's whether there might be a need to allow someone to input a T2* map that isn't generated directly from the multi-echo time series data? That is currently a viable option in tedana. I don't know if anyone has specifically evaluated if it's better or worse. My sense it that there will be situations where a separately acquired, more empirical T2* map would be useful.
Apologies to all since I'm joining late to the party, and actually proposing related things on the PR Chris just linked.
Since I'm not an fMRIprep user, I don't completely follow the specific issue at hand here (@handwerkerd)
Totally understandable, sorry that the conversation is so unclear, and thanks for nonetheless responding!
Basically we are discussing the preferred order of operations when integrating tedana. Options are:
- STC + HMC + SDC + tedana
- STC + HMC + tedana + SDC (optimally combined, T2* map)
(STC=slice-timing correction, HMC=head-motion correction, SDC=susceptibility-distortion correction)
This far, it seems that option (2) is preferred https://github.com/nipreps/fmriprep/issues/2542#issuecomment-934512284. That means: each echo is corrected for slice-times and head-motion. Then t2smap_workflow from tedana is executed and the outputs of that corrected for susceptibility distortions (unwarped).
However, as I discuss in #2610, option (1) seems preferable for the following reasons
- fMRIPrep runs HMC and SDC all at once, so potential arguments about the unnecessary smoothing of the data because of multiple resamplings go away.
- fMRIPrep will (it doesn't yet) also modulate the distortion with the Jacobian of the warping (again, within the one-shot resampling). This means that very bright outliers from signal pileup from compression will be attenuated, and some areas attenuated by expansions might be recovered. Overall (although I don't think it is a big deal for the most part) there's a chance that running HMC+SDC of each echo separately will end up providing more voxels with a sufficiently good fit for tedana not to discard them.
- Option 1 is more consistent with the single-echo workflow line (this one is probably superfluous from your standpoint at the moment)
We currently recommend using non-SDCed data in tedana, but we don't have any actual tests comparing pre-SDC vs post-SDC. (@tsalo)
Is this to say that there is about the same evidence to suggest one or another? In that case, if you were promised a very careful HM+SD one-shot correction, do you think what I mention above would be reasonable (i.e., tedana having to discard less bad voxels)?
On the other hand, there is the question of whether applying SDC on the T2* map or the optimal combination is safe. My impression is that the workflow is already very restrictive (in the sense that a fair amount of voxels around the vmPFC and temporal lobes will be dropped), so applying the nonlinear warping will definitely be tricky (if not unnecessary as distortions are smaller due to the acceleration of the sequence, and the fact that some regions have been completely erased due to dropout).
I agree that (2) is currently what we consider best practice. This is primarily because aggressive non-linear spatial warps, as typical for distortion correction, will almost definitely distort the relationship between echoes. There might be ways to adjust for this in how tedana calculates multi-echo metrics and uses them for selecting components to reject, but that's a non-trivial bit of work.
I've recently been thinking about a proposal that might address this issue. The end of the component selection process is a list of ICA components to reject. Denoising is effectively regressing those time series from the inputted data. A plausible processing pipeline would be STC -> HMC -> tedana -> time series from rejected components STC -> HMC+SDC -> regress time series from rejected components to these data
This approach has not been validated or even implemented, but I was already talking about something similar to this for including respiration regressors. It might also be a way to balance the need to generate components that retain the relationship between echoes, but actually denoise the data that only had one applied spatial transform.
In the context of this thread, we also want to output derivative echos for flexible use in Tedana. So from fMRIPrep's perspective, it sounds like we want to run SDC before calculating the T2*-map + OC, but not for the derivative echos:
- EchoN -> STC -> HMC -> SDC -> Tedana -> Optimal combination
- EchoN -> STC -> HMC -> Derivative echos
If fMRIPrep incorporates the tedana decomposition into it, then we can also have:
- EchoN -> STC -> HMC -> Tedana -> Components
I assume there's no plausible way to cast the optimal combination as just another transform in a sequence so that we could single shot?
- EchoN -> STC -> (HMC + OC + SDC + Aff + Warp) -> Optimal combination in target space
it sounds like we want to run SDC before calculating the T2*-map + OC, but not for the derivative echos
why not the derivative echos? seems a bit concerning if you are feeding something different to tedana, wdyt?
It doesn't seem like this problem has been comprehensively explored, so I would lean towards option 1, with the expectation that we will provide feedback to tedana about that choice and form some knowledge base.
it sounds like we want to run SDC before calculating the T2*-map + OC, but not for the derivative echos
why not the derivative echos? seems a bit concerning if you are feeding something different to tedana, wdyt?
Because the goal is to provide as clean as possible inputs to Tedana for calculating the noise components that you want to remove. This was @handwerkerd's suggestion.
So the cleanest way forward in the short term is going to be to continue fully-correcting (i.e., including SDC) each echo before before running Tedana (for T2* map and OC) or sinking individual echos as derivatives.
This should at any rate not degrade the current ability to integrate fMRIPrep+Tedana.
We'll also be outputting preprocessed fieldmaps, which would allow a user to run with/without SDC, run tedana on the SDC-free and then correct those results with the fieldmaps from the SDC run. From there we can assess whether it's worth significantly complicating the workflow.
I agree that outputting pre-SDC echo-wise derivatives shouldn't be a high priority. Outputting post-SDC echo-wise derivatives and running tedana on those files within the workflow sounds like a clean way to do things.
I'll stay out of the prioritization Q so I might be missing something in @tsalo's comment. I do agree with @effigies that the current approach would say do both: EchoN -> STC -> HMC -> SDC -> Tedana just for Optimal combination EchoN -> STC -> HMC -> Derivative echos -> Tedana for multi-echo denoising
That said, the spatial interpolation issues with SDC might affect the quality of the optimal combination, but not enough to really care about. Optimal combination is the weighted average of each of the echoes and if those weights are slightly off, it's still a weighted average of the same underlying data.
To come back to the T2* map question:
@effigies:
Would people just want the raw T2* map or transformed into the
--output-space-declared spaces, or both?@tsalo:
The main benefit is in running tedana, but it can also be useful for QC. I don't know if that QC needs to be in standard space, but it could help. That said, I don't think it's a big deal if the T2* map is just in boldref space. @handwerkerd do you think a standard space T2* map would be necessary?
@handwerkerd
If I get the part where you're asking me a question, it's whether there might be a need to allow someone to input a T2* map that isn't generated directly from the multi-echo time series data?
The question is "What would be useful to somebody using preprocessed ME data?" Assuming you're interested in either assessing the quality of preprocessing or doing further processing with Tedana. We can output T2* maps as directly generated by Tedana, or transform them into another space.
It seems the can be regenerated at-will from the individual echos, but would they save processing time to have available? And if they are useful for QC, in what space(s) would they be most useful to be sampled?
Sorry for the delay. For the sake of using ME data, I don't think there's any benefit to outputting the T2* map in anything other than the space in which tedana generated it ("scanner" or "boldref").
It seems the can be regenerated at-will from the individual echos, but would they save processing time to have available?
It won't generally save much time to have the T2* map saved instead of generating it again from the individual echos.
And if they are useful for QC, in what space(s) would they be most useful to be sampled?
It could be helpful to make sure that the T2* map looks reasonable, but I don't think it's necessary. Maybe it's just something that can be added in the future if folks request it? If it was being used for QC, then I'd say that standard space would be the way to go.
I noticed that multi-echo _boldref derivatives are skullstriped while the single-echo aren't. I am not sure the source of that discrepancy, and it might be related to #2891 . (fmriprep 22.0.2)
