Fmriprep: Suggestion to add list of pipeline steps to report

[ritcheym]

A small suggestion:

I am trying to check that fmriprep has run correctly on a new dataset, and there are a couple of steps I can't verify-- for instance, I can't tell from the report or the output files whether slice-timing actually ran. It'd be useful to have a list of all pipeline steps (completed, skipped, or failed) included in the report file, whether there's a corresponding visualization or not. I imagine I can dig through the terminal output, but better to have it saved in the stand-alone report. Thanks!

[effigies]

This sounds like a good idea to me. We generally like there to be a visual for each step, so that users can verify that the step worked correctly, but in cases where we don't (yet) have a way of doing that, noting that it was done really seems like a minimal requirement.

Just to start a list of points worth noting:

• Anatomical
  
  
  
  • Number of averaged images
  
  
  • FreeSurfer reconstruction (yes/no/pre-run subject found)
  
  
  • Target templates (MNI, fsaverage, etc.)
  
  
• Functional (each one, as the available metadata can differ)
  
  
  
  • Slice-timing correctiong
  
  
  • Susceptibility distortion correction method (fmap, phdiff, SyN, none)
  
  
  • T1w registration method (FSL FLIRT w/ BBR metric, or FreeSurfer bbregister)
  
  
  • Output spaces (T1w, MNI, fsaverage, etc...)
  
  
  • Confound methods
  
  

I'm not sure whether it would be best to include this in the report itself (some of course already is); we also have discussed adding a README (related: #268) which would include the version of FMRIPREP run. It might make sense to also include the above-listed information, and perhaps also the full command that was run.

Let me know what you think, as a user. Both in terms of the content of such a summary and whether you'd rather have it in the report, or if a README that can be referenced without cluttering up the HTML report would be better.

[ritcheym]

For content, yes, I was imagining a list of steps + methods like the one you included.

I suspect that it would be most useful to have the list contained in the report, so that the file can live on as a self-contained record. If it's only text, then it could be appended to the end without adding much clutter. But I see the BIDS-based argument for including this type of info in the README file... at minimum, the README could be linked in the report.

[chrisgorgo]

I prefer the reports as well since writing to the same README file from parallel jobs might be problematic. Self contained nature of reports is another reason why to do it. Great idea @ritcheym!