You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
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).
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?
The text was updated successfully, but these errors were encountered:
This applies to
phys2denoise
as well, but I figured I'd raise it here becausepeakdet
would presumably be run beforephys2denoise
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:peakdet
+phys2denoise
outputs do not fit withinfmriprep
or any other specific workflow's output folder, so we should have our own. That said,peakdet
andphys2denoise
outputs probably do belong together.phys2denoise
is probably a good choice, but what about something likemanual-qc
, with the idea that other modalities' manual QC outputs could go there too?peakdet
outputs are BIDS Derivatives-compatible.csv
+ an associated historyjson
. We can easily changecsv
totsv.gz
.json
file to be as BIDS compatible as possible.recording
with the channel name and can add adesc
field with a useful value like "peakQC" or "cleaned" or something.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 fromphys2denoise
(see below).phys2denoise
outputs are BIDS Derivatives-compatible.confounds.tsv
file likefMRIPrep
makes.The text was updated successfully, but these errors were encountered: