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

Matching BIDS-Derivatives convention #16

Open
tsalo opened this issue Jul 4, 2020 · 0 comments
Open

Matching BIDS-Derivatives convention #16

tsalo opened this issue Jul 4, 2020 · 0 comments

Comments

@tsalo
Copy link
Member

tsalo commented Jul 4, 2020

This applies to phys2denoise as well, but I figured I'd raise it here because peakdet would presumably be run before phys2denoise in folks' pipelines. Basically, I think we should figure out how these two steps should be written out to match Derivatives convention. I see a few steps:

  1. Decide on a standard derivatives folder name.
    • The peakdet + phys2denoise outputs do not fit within fmriprep or any other specific workflow's output folder, so we should have our own. That said, peakdet and phys2denoise outputs probably do belong together.
    • phys2denoise is probably a good choice, but what about something like manual-qc, with the idea that other modalities' manual QC outputs could go there too?
  2. Ensure that peakdet outputs are BIDS Derivatives-compatible.
    • Right now, outputs are a channel-specific csv + an associated history json. We can easily change csv to tsv.gz.
    • We can also restructure the json file to be as BIDS compatible as possible.
    • Finally, we can infer the output filenames from the input filename. For the output filename, we can replace recording with the channel name and can add a desc field with a useful value like "peakQC" or "cleaned" or something.
    • Although... should manual annotations be split by annotator? I realize that we don't expect multiple people to do manual QC on the same data, except when training new quality controllers, but it does seem like something we should account for.
      • Perhaps we could use desc for the annotator name or put it somewhere in the json. Or we could put it in the scans.tsv file, which would fit well with the summary metrics we get from phys2denoise (see below).
  3. Ensure that phys2denoise outputs are BIDS Derivatives-compatible.
    • Most of the outputs will be volume-wise time series, so those can go in a confounds.tsv file like fMRIPrep makes.
    • For the summary metrics (like RPV), I'm not sure about where those are supposed to go. Does Derivatives support scans-like files?
@m-miedema m-miedema transferred this issue from physiopy/peakdet Jul 25, 2024
@tsalo tsalo removed their assignment Jul 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: BrainHack Vanderbilt 2024
Development

No branches or pull requests

1 participant