-
Notifications
You must be signed in to change notification settings - Fork 95
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
Change decomposition files from json back to tsv #649
Comments
Somehow I forgot updates to the fMRIPrep/BIDS conversation (see summary at nipreps/fmripost-aroma#10), but basically the BIDS maintainers agreed to stick with json files for the immediate future. However, I'm still leaning toward using a TSV here and in the |
Here's what I'm thinking: desc-ICA_mixing.tsv (required)
desc-ICA_decomposition.json (required){
"Method": "Independent components analysis with FastICA algorithm implemented by sklearn. Components are sorted by Kappa in descending order. Component signs are flipped to best match the data.",
"ica_00": {
"Description": "ICA fit to dimensionally-reduced optimally combined data.",
"Method": "tedana"
},
"ica_01": {
"Description": "ICA fit to dimensionally-reduced optimally combined data.",
"Method": "tedana"
},
"ica_02": {
"Description": "ICA fit to dimensionally-reduced optimally combined data.",
"Method": "tedana"
},
"ica_03": {
"Description": "ICA fit to dimensionally-reduced optimally combined data.",
"Method": "tedana"
},
"ica_04": {
"Description": "ICA fit to dimensionally-reduced optimally combined data.",
"Method": "tedana"
}
} desc-ICA_metrics.tsv (new)
desc-ICA_metrics.json (new){
"Component": {
"Description": "The unique identifier of each component. This identifier matches column names in the mixing matrix TSV file.",
"LongName": "Component identifier"
},
"classification": {
"Description": "Classification from the classification procedure.",
"Levels": {
"accepted": "A BOLD-like component included in denoised and high-Kappa data.",
"ignored": "A low-variance component included in denoised, but excluded from high-Kappa data.",
"rejected": "A non-BOLD component excluded from denoised and high-Kappa data."
},
"LongName": "Component classification"
},
"countnoise": {
"Description": "Number of 'noise' voxels (voxels highly weighted for component, but not from clusters) from each component.",
"LongName": "Noise voxel count",
"Units": "voxel"
},
"countsigFR2": {
"Description": "Number of significant voxels from the cluster-extent thresholded R2 model F-statistic map for each component.",
"LongName": "R2 model F-statistic map significant voxel count",
"Units": "voxel"
},
} |
Sounds good to me! |
They look beautiful ! Per the linked fMRIPrep discussion, though, does that mean these files are not BIDS compatible for the moment ? |
From what I recall, there is nothing in the derivatives spec prohibiting them, and I think that they are ultimately cleaner than a pure-json approach, but I can't guarantee that other tools (especially fMRIPrep) will want to adopt this approach. That's part of why I want input on ME-ICA/aroma#5 as well. |
One other thing we could do is use |
Summary
We originally had our component tables stored in TSV format, but we switched to JSONs in nipreps/fmriprep#456 to better match BIDS Derivatives convention. However, after discussing the issue with some of the BIDS folks recently (please see nipreps/fmripost-aroma#10), it sounds like a TSV is more flexible and is BIDS Derivatives-compatible. We can still place metadata about the components/decomposition in a JSON.
Additional Detail
Next Steps
The text was updated successfully, but these errors were encountered: