Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable longitudinal structural analysis #429

Open
ChristianNSchmitz opened this issue Nov 15, 2023 · 13 comments
Open

Enable longitudinal structural analysis #429

ChristianNSchmitz opened this issue Nov 15, 2023 · 13 comments
Labels
effort:medium Estimated medium effort task freesurfer FreeSurfer related improvements and issues impact:high Estimated high impact task

Comments

@ChristianNSchmitz
Copy link

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

@effigies
Copy link
Member

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.

@Beatrizfg20
Copy link

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?

@oesteban oesteban transferred this issue from nipreps/fmriprep Apr 9, 2024
@oesteban oesteban added freesurfer FreeSurfer related improvements and issues effort:medium Estimated medium effort task impact:high Estimated high impact task labels Apr 9, 2024
@bpinsard
Copy link
Contributor

bpinsard commented May 7, 2024

@Beatrizfg20 yes, I recently added this feature here nipreps/fmriprep#3142 / #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.

@tsalo
Copy link
Collaborator

tsalo commented Oct 14, 2024

@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:

  1. Accept a value for the --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.
  2. A separate parameter that's mutually exclusive with --longitudinal, like --session-wise-anatomical.
  3. Change the behavior of --longitudinal to perform session-wise processing.
  4. Enable session-wise anatomical processing by default, like how (I think) Nibabies works.

EDIT: BTW this seems related to #31.

@tsalo
Copy link
Collaborator

tsalo commented Oct 15, 2024

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:

  1. Users are not using the --longitudinal flag as it is currently implemented.
  2. It's straightforward to create an unbiased average and to use that as a target space (i.e., reproducing the current longitudinal approach) with other tools.

I'm fine with those assumptions, but I want to get feedback from other folks before making any breaking changes.

@bpinsard
Copy link
Contributor

That sound amazing!
So this would follow the freesurfer longitudinal workflow? such as:

  • select 1 T1w (+T2w) per session, or mri_robust_average all available T1w (+T2w) per session? (with bids-filters applied)
  • apply smriprep skull-stripping rather than relying on the freesurfer one (less robust).
  • run the cross-sectional on each session, then base template, then longitudinal on each session?
  • use the freesurfer base template as the ref for all sessions, or each longitudinal session?

@tsalo
Copy link
Collaborator

tsalo commented Oct 15, 2024

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.

@bpinsard
Copy link
Contributor

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.

@bpinsard
Copy link
Contributor

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)

@cookpa
Copy link

cookpa commented Oct 15, 2024

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).

@tsalo
Copy link
Collaborator

tsalo commented Oct 21, 2024

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?

@tsalo
Copy link
Collaborator

tsalo commented Oct 29, 2024

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).

@tsalo
Copy link
Collaborator

tsalo commented Nov 1, 2024

@mattcieslak recently implemented this in QSIPrep and I think his PR (PennLINC/qsiprep#832) is a good indicator of the changes we'll need to make in sMRIPrep (or at least fMRIPrep).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort:medium Estimated medium effort task freesurfer FreeSurfer related improvements and issues impact:high Estimated high impact task
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants