-
Notifications
You must be signed in to change notification settings - Fork 0
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
I/O spec for AFNI BIDS outputs #6
Comments
AFNI outputs a file name registry that can be mapped onto any file name structure. I know there was work to make a BIDS mapping, but I'm not sure of the current status. @mrneont might know more details. |
@tsalo : sorry for delay in reply, been away on leave. The main FMRI pipeline tool in AFNI is afni_proc.py. This is typically used to fully process a single subject dataset through regression modeling (GLM). First, afni_proc.py generates a commented script that records all the processing that will take place, and running that script generates a standard results directory of both copied, intermediate and final data, as well as QC HTML and other quantitative records of the processing. Since afni_proc.py can be used pretty flexibly (surface or volume; ROI-based or voxelwise; final space being template, or subject anatomical, or subject EPI; including blip up/down or not; etc.), there can be a wide array of outputs. To help keep track of all this, the afni_proc.py script generates a dictionary of meaningful outputs each time. This is called the "uvar dictionary", where the keys are variables for the user to know about what the output of interest is. This is described in this recent paper:
That being said, AFNI now also has a
In recent discussion with BIDS developers at OHBM Brainhack, we discussed that if other FMRI pipeline tools had a dictionary of meaningful outputs, analogous to afni_proc.py's uvar dictionary, then it would be straightforward to map all outputs across pipelines. In some sense, we have already worked on a mapping from afni_proc.py to current BIDS Derivatives, because we can map the afni_proc.py uvars to a given naming structure that BIDS Derivatives has defined. Dictionaries would likely overlap partially and not completely, because different pipelines do different things (such is the case with afni_proc.py and current BIDS Derivatives), but that is certainly fine. Having a mapping between the major outputs seems the key thing, because these are adaptable even if things like filenames (which are the essentially values in the dictionary) change. Happy to hear your thoughts on this. --pt |
Thanks @mrneont. I think I misunderstood the
I will take a look at the uvars dictionary to see if that's what I should reference in fMRIPost-tedana. I might write an ingression script to convert the outputs to a BIDS-like format based on that dictionary, so fMRIPost-tedana can just use pybids to collect the necessary files on its end. |
Hi, @tsalo : Adding "-bids_deriv yes" to the afni_proc.py command means that all the afni_proc.py outputs that exist in a BIDS Derivative naming convention are mapped to that. There are many other afni_proc.py outputs that just don't have a known home there at present---though please let us know if you think there are others that are ready to be mapped---and indeed I suspect there might be other BIDS Derivatives outputs from other software that afni_proc.py doesn't make. If there are some that might be addable, please also ping and we can discuss if they could be added when this option is used. It should also be noted that the existing afni_proc.py-to-BIDS-Derivatives mapping was done with invaluable the help of Chris Marciewicz and Dylan Nielson. Checking out the uvars sounds good---that is the set of major afni_proc.py outputs from processing, which are used in generating the APQC HTML report, as well as mapping to BIDS Derivatives. Happy to hear your thoughts on this. |
Does anyone know what AFNI BIDS derivatives look like?
The text was updated successfully, but these errors were encountered: