search

nipreps / fmriprep

fMRIPrep is a robust and easy-to-use pipeline for preprocessing of diverse fMRI data. The transparent workflow dispenses of manual intervention, thereby ensuring the reproducibility of the results.
https://fmriprep.org
Apache License 2.0
620 stars 290 forks source link

List preprocessing options in the derivatives sidecar files #2219

Open bpinsard opened 4 years ago

bpinsard commented 4 years ago

Correct me if I am wrong but, for now, information such as which sdcflows method was applied is only visible in the html report. It would be great to have it in the sidecar json to be parsable with pybids for instance.

I am mainly thinking about sdcflows method as it can vary across the dataset if no fieldmap is found, but the sidecar could contain other info (slicetiming, ....). It would be useful when derivatives are redistributed/shared.

I guess it would be mostly coded in niworkflow.

What do you think?

oesteban commented 4 years ago

This looks like encoding provenance into the BIDS-Derivatives folder, right @satra?

I agree fMRIPrep could be more explicit (and machine readable) in this regard, but also feel that the new config modules covers this suggestion in a, say, 80%.

I think this should be planned out under the scope of BIDS as a BEP (there is one by Satra, actually), and then fMRIPrep should just implement the specification.

WDYT?

bpinsard commented 4 years ago

Sounds like a good plan. We would need to aggregate general preprocessing steps as listed in BEP012 and feed them to niworkflows.bids.DerivativesDataSink.

On top of my head, only two run-specific info that cannot be 100% accurate based on the config file:

satra commented 4 years ago

@bpinsard - the current working proposal for provenance is BEP028. what would still be useful with respect to BEP012 is to create a vocabulary of processing steps like the EDAM onotology has for bioinformatics.

@oesteban - i do want to clarify one point. the specification is a starting point, but technically only part of provenance. the config is an input and therefore captures instructions to fmriprep, but provenance should capture what fmriprep does with those instructions. for example, a bug in the code could mean that internally somewhere the specifications are not being used. however, at what level fmriprep chooses to capture provenance is going to be up to fmriprep and the community.

level 0: input config, docker checksum, outputs level 1: input config, docker checksum, outputs, runtime information level 2: input config, docker checksum, outputs, runtime information, provenance of sub workflows level 3: input config, docker checksum, outputs, runtime information, provenance of sub workflows, provenance of each function/interface