Open ChristianNSchmitz opened 1 year ago
Hi @ChristianNSchmitz, yes this is on our roadmap for 2024. This behavior is currently implemented in nibabies, so we expect to be able to implement it in fMRIPrep.
Hello! Have any of you already tried using the FreeSurfer outputs with a longitudinal structure in fMRIPrep? I am very interested in using it in that way. Could you clarify which should be the FreeSurfer folder structure?
@Beatrizfg20 yes, I recently added this feature here https://github.com/nipreps/fmriprep/pull/3142 / https://github.com/nipreps/smriprep/pull/393 to just do that. I applied this on our dataset, though I used smriprep first steps on the raw T1w/T2w images before feeding these to freesurfer cross-sectional (as it was more robust for skull-stripping), then ran the base and longitudinal templates and provided these to smriprep anat-only to then use it with fmriprep.
@mattcieslak and I are interested in implementing the same option in QSIPrep and we want to ensure that QSIPrep's approach matches sMRIPrep's. Does anyone have any thoughts on what the parameters to enable this would look like?
We had a few ideas:
--longitudinal
parameter.
--longitudinal register-to-first
: The current default behavior, where everything's registered to the first anatomical scan.--longitudinal unbiased-template
or --longitudinal
: How --longitudinal
currently works, where an unbiased template is generated.--longitudinal session-wise
: The new proposed behavior, where each session is analyzed separately.--longitudinal
, like --session-wise-anatomical
.--longitudinal
to perform session-wise processing.EDIT: BTW this seems related to #31.
From today's NiPreps TechMon meeting, the current plan is to (1) deprecate the --longitudinal
flag in both sMRIPrep and fMRIPrep in the current series and (2) make --longitudinal
implement session-wise anatomical processing in the next major release. This will be a breaking change.
This plan is predicated on two assumptions AFAICT:
--longitudinal
flag as it is currently implemented.I'm fine with those assumptions, but I want to get feedback from other folks before making any breaking changes.
That sound amazing! So this would follow the freesurfer longitudinal workflow? such as:
The current proposal would just run the standard sMRIPrep workflow separately on each session, like how Nibabies currently works. The idea is that the current approach doesn't work in two key cases: (1) with ongoing studies where you want to process incoming data without reprocessing all of the past data, like ABCD or HBCD and (2) when there are massive changes in subjects' brains across sessions, like with developmental datasets (again including ABCD and HBCD).
I think that, in the case of multiple anatomical scans in the same session, sMRIPrep would register each of the anatomical scans in a given session to the first anatomical in that session, rather than running mri_robust_average
on all of them.
If you think a more intricate longitudinal pipeline is necessary/better, then I think that's a vote against the current proposal, and we need to consider something like option 1 in my earlier comment.
I don't vote against. The complexity of the freesurfer longitudinal pipelines doesn't have to be built-in into sMRIPrep as this is very constraining (and computationally costly), as long as one can input existing preprocessed results into the pipelines, as it is now possible with the --fs-no-resume
option.
Also +1 on deprecating the --longitudinal
flag that is misleading users (including me many years ago) into thinking it would do all the freesurfer longitudinal pipelines)
Hi all,
I heard about this thread from @tsalo but jumping in with my own opinions, FWIW.
I understand that users are not using --longitudinal
very much. I can think of two reasons for this other than that they don't want it. Firstly is the data, some users don't have longitudinal data, or they have longitudinal data with two time points. Only people with three or more sessions even need --longitudinal
as implemented, which is going to be a minority of cases. Further, it's very common in my work that investigators want to run cross-sectional analyses before they've completed the longitudinal data acquisition, further weighting usage away from the --longitudinal
flag.
Secondly, even with 3+ sessions, the preps will run happily without this flag. Users will see their output in a common anatomical reference space, and only the detail-oriented will read the explanation that it is being done in a sub-optimal way and then re-run with --longitudinal
.
I do think it would be very useful to have an option to process sessions independently. In fact, I would make that the default, or at least call it something other than "longitudinal", to avoid confusion.
Perhaps as @bpinsard says, it's best to abandon the term altogether. Have something like --subject-anatomical-reference [unbiased|first|none]
(default=none for independent session processing). To make clear that only the anatomical reference image is being processed longitudinally.
I do think though that it would be a mistake to use --longitudinal
to mean not-longitudinal (as in option 3 of the post upthread).
I vote for adding a new parameter and dropping longitudinal. --subject-anatomical-reference [unbiased|first|none]
seems good to me, and it would make it possible to support the full Freesurfer longitudinal pipeline in the future (moreso than a binary flag like --longitudinal
at least).
Does anyone have an issue with that plan?
Per today's techmon meeting, everyone's okay with this general approach, but none
should be changed to sessionwise
and first
might be better labeled as first-alphabetically
(e.g., if the two sessions are pre
and post
sMRIPrep will use post
).
@mattcieslak recently implemented this in QSIPrep and I think his PR (https://github.com/PennLINC/qsiprep/pull/832) is a good indicator of the changes we'll need to make in sMRIPrep (or at least fMRIPrep).
What would you like to see added in fMRIPrep?
Dear fMRIPrep-Team,
we are currently working with longitudinal data and would like to use the strucutral freesurfer-output for further analysis. Unfortunately, fMRIPrep creates an average image of all T1 weighted images and only the tweak with the flag --bids-filter-file enables the separate analysis of different sessions. Thus, we would like to ask you if a separate structural analysis of different sessions would be possible.
Best, Christian
Do you have any interest in helping implement the feature?
Yes
Additional information / screenshots
No response