[ENH] Derived (processed) MR data#109
[ENH] Derived (processed) MR data#109chrisgorgo merged 112 commits intobids-standard:derivativesfrom
Conversation
arokem
left a comment
There was a problem hiding this comment.
A few small comments on the dMRI part.
This comment has been minimized.
This comment has been minimized.
Co-Authored-By: chrisfilo <krzysztof.gorgolewski@gmail.com>
Co-Authored-By: chrisfilo <krzysztof.gorgolewski@gmail.com>
Co-Authored-By: chrisfilo <krzysztof.gorgolewski@gmail.com>
Co-Authored-By: chrisfilo <krzysztof.gorgolewski@gmail.com>
Co-Authored-By: chrisfilo <krzysztof.gorgolewski@gmail.com>
Co-Authored-By: chrisfilo <krzysztof.gorgolewski@gmail.com>
Co-Authored-By: chrisfilo <krzysztof.gorgolewski@gmail.com>
Co-Authored-By: chrisfilo <krzysztof.gorgolewski@gmail.com>
…into enh/derivatives
…ication into enh/space_examples
| | MNI152Lin | Also known as ICBM (version with linear coregistration) [http://www.bic.mni.mcgill.ca/ServicesAtlases/ICBM152Lin](http://www.bic.mni.mcgill.ca/ServicesAtlases/ICBM152Lin) | | ||
| | MNI152NLin6\[Sym|Asym\] | Also known as ICBM 6th generation (non-linear coregistration). Used by SPM99 - SPM8 and FSL (MNI152NLin6Sym). [http://www.bic.mni.mcgill.ca/ServicesAtlases/ICBM152NLin6](http://www.bic.mni.mcgill.ca/ServicesAtlases/ICBM152NLin6) | | ||
| | MNI152NLin6\[Sym|Asym\] | Also known as ICBM 6th generation (non-linear coregistration). Used by SPM99 - SPM8 and FSL (MNI152NLin6Sym). [http://www.bic.mni.mcgill.ca/ServicesAtlases/ICBM152NLin6](http://www.bic.mni.mcgill.ca/ServicesAtlases/ICBM152NLin6) | | ||
| | MNI152NLin6AsymConte69 | Template based on MNI152NLin6Asym using Conte69 data. Built by Human Connectome Project. [https://github.com/Washington-University/HCPpipelines/tree/master/global/templates](https://github.com/Washington-University/HCPpipelines/tree/master/global/templates) | |
There was a problem hiding this comment.
IMHO This should be fsLR. Space has no notion of surfaces or volumes.
There was a problem hiding this comment.
If you think fsLR for this volume space defined by a volume template would be more intuitive we can change it. Pinging @edickie for second opinion.
There was a problem hiding this comment.
I dunno, I don't really know MNI152NLin6AsymConte69 (I actually just register to MNI152NLin6Sym in my workflows anyway..)
| | Coordinate System | Description | | ||
| | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | FS305 | FreeSurfer variant of the MNI305 space | |
There was a problem hiding this comment.
This should be implicit to fsaverage* for the same reasons of MNI152NLin6AsymConte69 should not be a space. This example clearly shows how sampling should be detached from the notion of space.
There was a problem hiding this comment.
This is just a label, but it should not include any special character (such as *), so if anything fsaverage can be used. I not familiar with this space though - @edickie did you add this one?
[ENH] replacing `CoordinateSystem` replacement with `space` + examples
effigies
left a comment
There was a problem hiding this comment.
Inconsistencies with L221.
| pipeline/ | ||
| sub-001/ | ||
| anat/ | ||
| sub-001_hemi-L_dparc.label.gii |
There was a problem hiding this comment.
| sub-001_hemi-L_dparc.label.gii | |
| sub-001_hemi-L_dseg.label.gii |
| sub-001/ | ||
| anat/ | ||
| sub-001_hemi-L_dparc.label.gii | ||
| sub-001_hemi-R_dparc.label.gii |
There was a problem hiding this comment.
| sub-001_hemi-R_dparc.label.gii | |
| sub-001_hemi-R_dseg.label.gii |
| pipeline/ | ||
| sub-001/ | ||
| anat/ | ||
| sub-001_dparc.dlabel.nii |
There was a problem hiding this comment.
| sub-001_dparc.dlabel.nii | |
| sub-001_dseg.dlabel.nii |
| sub-001/ | ||
| anat/ | ||
| sub-001_dparc.dlabel.nii | ||
| sub-001_dparc.dlabel.nii |
There was a problem hiding this comment.
| sub-001_dparc.dlabel.nii | |
| sub-001_dseg.dlabel.nii |
There was a problem hiding this comment.
Yeah. I think there is a history of referring to atlases in nifti as segmentation and atlases on the surface as parcellations, so _dseg and _dparc suffixes appeared. but I agree that there is no reason for this.
|
Hi @bids-standard/bep_leads, would it make sense to merge this PR into a branch under the upstream repo so @sappelhoff has better handles over the conversation (in a new PR)? WDYT @chrisgorgo, wouldn't that release you from moderating this PR? |
|
Yes this would indeed facilitate someone else taking over chaperoning this
PR. Happy to facilitate this process if someone wants to take over.
Best,
Chris
…On Wed, Apr 10, 2019 at 4:04 PM Oscar Esteban ***@***.***> wrote:
Hi @bids-standard/bep_leads
<https://github.com/orgs/bids-standard/teams/bep_leads>, would it make
sense to merge this PR into a branch under the upstream repo so
@sappelhoff <https://github.com/sappelhoff> has better handles over the
conversation (in a new PR)? WDYT @chrisgorgo
<https://github.com/chrisgorgo>, wouldn't that release you from
moderating this PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#109 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOkpwrW-dbGikSyPb4R0pqwNbxEnrZgks5vfm3xgaJpZM4ZVavQ>
.
|
|
I have just pushed a fresh "derivatives" branch to our bids-standard/bids-specification repo. We could merge this present branch into I'd prefer if @chrisgorgo could do that however, because there is this scary warning: Then once we have changed base and merged this PR, we can make a new PR from the |
|
Updated the base branch. @chrisfilo, if you can resolve conflicts, we can get this off your plate. |
|
@sappelhoff I didn't see your request that @chrisgorgo do the base change. Very sorry about that. |
…into enh/derivatives


This PR culminates over two years of discussions and work on BIDS Derivatives. I derived it from our RC1 Google Document with the following changes:
SpaceJSON metadata field - it was never properly described and seemed redundant withReferenceMapdesc-manualrestricted key/value pair with a JSON field (for segmentation)labelto useAbbreviationin the context of segmentation metadata (instead of index, context or name which was too flexible)qform/sformin tractography metadata in this PR since it seems not well described and quite controversial.Param1,Param2etc. so I also left them out.Calling @effigies @satra @sgiavasis @oesteban @edickie @francopestilli @nicholst @tyarkoni @ahoopes for validation and comments. Please send suggestions via PRs to https://github.com/chrisfilo/bids-specification/tree/enh/derivatives.
I'll try to work on examples and the validator over the xmas break. Many thanks to everyone who contributed to this work.