[ENH] Derived (processed) MR data #207

effigies · 2019-04-16T13:17:13Z

This replaces #109, tracking the state of the derivatives BEP as we finalize.

The current state of this branch will be rendered on https://bids-specification.readthedocs.io/en/derivatives/

Depends on #205, #167.

sappelhoff

part 1/n of reviewing. I stopped at src/05-derivatives/01-introduction.md for now. Will return soon.

CODEOWNERS

src/02-common-principles.md

sappelhoff · 2019-04-18T16:41:54Z

src/02-common-principles.md

-example is just a convention that can be useful for organizing raw, source, and 
-derived data while maintaining BIDS compliancy of the raw data folder.
+In this example **only `rawdata` subfolder and all subfolders of `derivatives`**
+**need to be BIDS compliant** datasets. This specification does not prescribe 


So with this BEP the /derivatives will be defined for MRI data and it makes sense to then enforce that the contents of /derivatives is formatted according to the rules. However,

are there any bids-validator functions in place yet?

All other modalities will lose the "convenience" of using /derivatives as a dump

point 2. is probably fair enough and we'll simply have to work on BEP021.

are there any bids-validator functions in place yet?

Paging @rwblair.

Looks like currently any file located in derivatives is accepted:
https://github.com/bids-standard/bids-validator/blob/master/bids-validator/bids_validator/rules/associated_data_rules.json

So there is a function currently checking the directory but, we will need to expand the regexp to account for the standard.

src/05-derivatives/01-introduction.md

oesteban · 2019-04-25T23:57:24Z

src/99-appendices/08-coordinate-systems.md

 | 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&#124;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&#124;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)                                                                                                |


Is this really a new template or it is just the FSL MNI template with the addition of the 1.6mm isotropic sampling (and other resolutions too)? Is there a publication describing the procedure used in building the template in the case it is not a variation of existing ones?

Pinging @edickie, @satra, and also @glasserm and @tbbrown for a more informed response.

I'd need some more context as to what the question is.

Sorry, I wasn't clear. The question is whether these templates and related data (https://github.com/Washington-University/HCPpipelines/tree/master/global/templates) are derived from the MNI template packed with FSL, some other template (e.g. the 2009 wave of templates from MNI), or were entirely constructed with the specific purposes of HCP/HCP-Pipelines.

The MNI templates are based on FSL's nonlinear template.

I've made several changes to the table of template identifiers: - [x] Reordered template identifiers alphabetically - [x] Removed the distinction between surface templates and volumetric templates. After all, to properly apply a surface template one should first spatially normalize to a particular volumetric template. Although it is possible to create mixed templates (e.g. using ``MNI152Lin`` to generate a mapping for volumetric coordinates and then, say, ``fsLR`` for the surface after some surface mapping process), this option should be discouraged. Anyways, this discussion does not affect how the names of BIDS entities should be specified, since one can always describe how the template coordinates are generated with the information described in this PR. - [x] Removed ``MNI152NLin6AsymConte69`` because it does not define any new coordinate system (see bids-standard#207 (comment)), - [x] Marked DEPRECATED ``fsaverage[3|4|5|6|sym]` - [x] Added ``fsaverage`` and ``fsaverageSym`` corresponding to such deprecations. - [x] Removed ``FS305`` as it is now covered by ``fsaverage``. - [x] DEPRECATED modifiers of ``UNCInfant`` - [x] Reorganized subsections in "standard" vs "nonstandard" spaces.

sappelhoff

review part 2/n until 02-common-data-types.md now

src/05-derivatives/01-introduction.md

sappelhoff · 2019-04-26T16:28:15Z

src/05-derivatives/01-introduction.md

+    that were created from more than one source dataset. It is consistent with
+    BIDS principles for the `sourcedata/` subdirectory to be used to include or
+    reference the source dataset(s) as it existed when the derivatives were
+    generated. Likewise, any code used to generate the derivatives from the


It is consistent with
BIDS principles for the sourcedata/ subdirectory to be used to include or
reference the source dataset(s) as it existed when the derivatives were
generated.

This sentence is not very readable, please rephrase.

Please see updated text.

src/05-derivatives/01-introduction.md

effigies · 2019-05-28T16:45:04Z

Hi all, what is everybody's opinion on the state of this? I know we have #213 pending, but are there any other outstanding issues?

We're missing CODEOWNERS for 05-derivatives/01-introduction.md and 05-derivatives/02-common-data-types.md. Maybe what we can do is for all codeowners to have another read-through of their sections as well as the first two files, and make a post highlighting any potential issues.

Would anybody be willing to volunteer to read through the whole thing with an eye for conflicts between sections?

sappelhoff · 2019-06-07T11:54:03Z

src/05-derivatives/01-introduction.md

+higher up in the hierarchy of the derived dataset (according to
+[The Inheritance Principle](../02-common-principles.md#the-inheritance-principle))
+unless a particular derivative includes REQUIRED metadata fields in which case a
+JSON file is also REQUIRED.


I am currently working on a dataset with an anatomical T1w scan, on which I have run the freesurfer recon-all command. That creates a directory full of files:

surfer/sub-01$ tree . -L 2 . └── recon-all ├── bem ├── label ├── mri ├── scripts ├── src ├── stats ├── surf ├── tmp ├── touch └── trash

Would it make sense in this case to have a surfer/sub-01/recon-all.json file in which I specify the metadata such as the SpatialReference pointing to my T1w scan?

--> This would mean that sidecar JSONS can also be defined for derivatives directories, not only files

oesteban · 2019-06-11T09:01:34Z