fmriprep icon indicating copy to clipboard operation
fmriprep copied to clipboard

Drop FSL/``--fs-no-reconall`` workflow path

Open oesteban opened this issue 3 years ago • 3 comments

What would you like to see added in fMRIPrep?

I've come to the realization that maintaining --fs-no-reconall is costly, and more worryingly, provides a space for users to create different variants of derived data.

Another example of problems stemming from this choice is here: https://doi.org/10.1101/2021.12.01.470790

In this paper, the C-PAC authors implemented an fMRIPRep inside C-PAC. However, they implemented the --fs-no-reconall alternative. I think that is not too relevant for the purpose of the paper, but still attempted to suggest edits to the draft where this was made more clear in the interest of not misrepresenting fMRIPrep (I had, admittedly, very limited if any success on this, unfortunately).

Now, @mgxd is trying to sync nibabies with the new carpetplots, and idiosyncracies derived from maintaining this no-reconall workflow are basically not transferrable to nibabies (instead of one "carpetplot" parcellation, we will need to generate one equivalent parcellation for each cohort template in the reference standard space, which doesn't seem straightforward and worth the pain).

The only legitimate utility of this workflow is for developers to be able to debug without having to run freesufer for a start (or consequentially, without requesting users more data than strictly necessary). We will need to figure out some "debug mode" surgery that replaces the default bbr workflow entirely, and somehow figures out any other missing connection.

Do any voices oppose this simplification?

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

No response

oesteban avatar Jun 08 '22 14:06 oesteban

Hi ! I am a simple user of fmriprep but I want to say that I usually use the "no-reconall" option because 1/ the process is often not well perform on my patient images with some abnormalities (and even on healthy but old subjects); 2/ I don't use the surface stuff; 3/ it takes lot of time and memory. So please, don't say that "The only legitimate utility of this workflow is for developers" Thank you for all the work you share with the community! Isabelle

IFaillenot avatar Jul 07 '22 08:07 IFaillenot