referenceSpace attribute and possible values

[cmaumet]

This is a proposal made up with @nicholst, regarding the naming of CoordinateSpace and CoordinateSystem.

Currently CoordinateSpace is defined as an entity having the following attributes: Number of dimensions, Dimension of image, Voxel units, Voxel size, Voxel-world mapping and CoordinateSystem.

We propose to rename the coordinateSystem attribute in referenceSpace providing a coarse label for the space of the images. This does not specify template image used, or any details of the spatial normalisation / intersubject registration (that will be defined through provenance).

For the values taken by referenceSpace we suggest the following:

Label: short description	Link	used in
SubjectSpace: Reference space defined by the subject brain (no spatial normalisation applied).	-	FSL and SPM un-registered data
TalairachSpace: Reference space defined by the dissected brain used for the Talairach and Tournoux atlas.	Talairach
Colin27Space: Reference space defined by the "stereotaxic average of 27 T1-weighted MRI scans of the same individual".	COLIN27	SPM96 (cf. MRC CBSU Wiki)
Mni305Space: Reference space defined by the "average of 305 T1-weighted MRI scans, linearly transformed to Talairach space".	MNI305	-
IcbmMni152LinearSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, linearly transformed to Talairach space".	ICBM/MNI152 linear	SPM99 to SPM8 (cf. MRC CBSU Wiki and spm8/spm_templates.man)
IcbmMni152NonLinear2009aSymmetricSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, non-linearly transformed to MNI152 linear space".	ICBM MNI 152 non-linear 2009	-
IcbmMni152NonLinear2009aAsymmetricSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, non-linearly transformed to MNI152 linear space".	ICBM MNI 152 non-linear 2009	-
IcbmMni152NonLinear2009bSymmetricSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, non-linearly transformed to MNI152 linear space".	ICBM MNI 152 non-linear 2009	-
IcbmMni152NonLinear2009bAsymmetricSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, non-linearly transformed to MNI152 linear space".	ICBM MNI 152 non-linear 2009	-
IcbmMni152NonLinear2009cSymmetricSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, non-linearly transformed to MNI152 linear space".	ICBM MNI 152 non-linear 2009	-
IcbmMni152NonLinear2009cAsymmetricSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, non-linearly transformed to MNI152 linear space".	ICBM MNI 152 non-linear 2009	DARTEL toolbox in SPM12b (cf. spm12b/spm_templates.man)
IcbmMni152NonLinear2009aAsymmetricSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, non-linearly transformed to MNI152 linear space".	ICBM MNI 152 non-linear	-
IcbmMni152NonLinear6thGenerationSpace: Reference space defined by the "average of 152 T1-weighted MRI scans, linearly and non-linearly (6 iterations) transformed to form a symmetric model in Talairach space"	ICBM MNI 152 non-linear 6th generation	FSL (cf. FSL atlases page)
Icbm452AirSpace: Reference space defined by the "average of 452 T1-weighted MRIs of normal young adult brains" with "linear transforms of the subjects into the atlas space using a 12-parameter affine transformation"	ICBM 452 AIR12	-
Icbm452Warp5Space: Reference space defined by the "average of 452 T1-weighted MRIs of normal young adult brains" "based on a 5th order polynomial transformation into the atlas space"	ICBM 452 WARP5	-
Ixi549Space: Reference space defined by the average of the "549 [...] subjects from the IXI dataset" linearly transformed to ICBM MNI 452.	IXI dataset	SPM12b (cf. spm12b/spm_templates.man)
StandardizedSpace: Parent of all reference spaces except "Subject".	-	This is meant to be used for retrospective export when exact template is unknown.

[The short descriptions proposed here are not the definitive definitions and will need to be re-worked.]

The current names CoordinateSpace and referenceSpace are distinct from NiPy's CoordinateSystem, so no confusion should arise. A CoordinateSpace entity contains all the information readily available (while NiPy's CoordinateSystem requires named axes, which don't generally have but are implied by the referenceSpace attribute).

We explicitly avoid using "Atlas" or "Template", as we predict these will be useful for specific instances of labeled or continuous images, respectively.

[nicholst]

The IXI link is just a top-level website; I think this is a better link: http://biomedic.doc.ic.ac.uk/brain-development/index.php?n=Main.Datasets

[satra]

@cmaumet and @nicholst

two thoughts:

1. how these are generated:

all of these are associated with:

1. a set of images
2. a normalization algorithm
3. the previous template

over the years, people have kept the name of the space even though 2 and 3 have changed. i think that it's quite important for us to dissociate these components?

and then when these templates are used, please use different normalization algorithms.

1. how do we handle custom templates.

these are getting used more even with spm and fsl.

[cmaumet]

Hi @satra, thank you for your comments!

1. Do you think that these 3 key components of the generation process could be specified as part of the definition of each "space term"?
2. Good point about custom templates… Would it make sense to have:

Standard template:

  entity(niiri:coordinate_space_id_1,
    [prov:type = 'nidm:CoordinateSpace',
    prov:label = "Coordinate space 1" %% xsd:string,
    nidm:referenceSpace = 'nidm:IcbmMni152LinearSpace',
    …
    ])

Custom template:

  entity(niiri:coordinate_space_id_1,
    [prov:type = 'nidm:CoordinateSpace',
    prov:label = "Coordinate space 1" %% xsd:string,
    nidm:referenceSpace = 'niiri:my_custom_template',
    …
    ])
  entity(niiri:my_custom_template,
    [prov:type = 'nidm:CustomTemplate',
    prov:label = "My custom template" %% xsd:string,
    // Attributes to be defined later on?
    ])
 
   // Sub-tree describing the provenance of niiri:my_custom_template  

[satra]

@cmaumet - that sounds reasonable.

let's also make sure to include the provenance of nidm:IcbmMni152LinearSpace somewhere.

[jbpoline]

hey,

I'm a bit confused by the distinction of CoordinateSpace / ReferenceSpace /
CoordinateSystem

The later I have the definition clear enough: it's the mathematical one,
the referenceSpace is the name of the "Atlas" (implying a known or unknown
template), but not sure about coordinateSpace anymore (although I probably
could find it in the email threads ...)

cheers
JB

On 10 May 2014 11:41, Satrajit Ghosh notifications@github.com wrote:

@cmaumet https://github.com/cmaumet - that sounds reasonable.

let's also make sure to include the provenance of
nidm:IcbmMni152LinearSpace somewhere.

—
Reply to this email directly or view it on GitHubhttps://github.com/ni-/ni-dm/issues/52#issuecomment-42750397
.

[nicholst]

Let me record what I think is the lineage.

• We started with CoordinateSpace to record something like what the NIFTI header and SPM's volume structure holds (basic information on the array, and voxel-world-mapping).
• The coordinateSystem was an attribute of a CoordinateSpace, giving the canonical meaning to world space. We propose now to rename this referenceSpace (Please ignore my first letter capitalizations as they may all be wrong). We re-naming also to avoid confusion with NiPy's CoordinateSystem.

I've studied the NiPy API's Coord* functions, and it seems that our CoordinateSystem has everything there except the named axes. As we generally have no idea about axis except from a atlas space, I think names should live in coordinateSystem (but don't feel too strongly on this).

So! My proposal is that we use the existing CoordinateSpace and the renamed and revamped referenceSpace and call it it day.

@jbpoline : What do you think?

[jbpoline]

Hi

I think my point is that coordinateSystem has a clear definition, mapping
has a clear definition, and with those two we have what's needed to code
for most "images"

I like the "referenceSpace" as the name for a coordinate system that has a
mapping towards anatomical or other kind of labels (ie mni, etc as you
defined). And having a tuple (template, labelling) where labelling is a
mapping sounds clear as well.

I'm also guessing that we can have (dataArray, coordinateSystem, mapping)
representation of about anything, and add the names to the
coordinateSystem. So, let's say you have only a dataArray in a nifti file
format, you could set the mapping to be identity and the domain and range
coo. sys. to be the same (with axes named as "i" "j" "k"). For an image in
the mni, the axis labels could be x-LR, y-PA (posterior to anterior), z-IS
(inferior to superior).

So, a template is a dataArray with a specific named coordinate system,
becaue it has both a dataArray and a specific meaning for the "world" space

An Atlas is a mapping from the space described by a coordinateSystem to a
set of labels. eg the Desikan / Tourville labelling, but that is
independant on the template

Again, the names of these things don't matter to me very much unless they
have already a precise mathematical definition

I'm happy to call it a day - just want to make sure we are not in a local
minima.

Let's talk tomorrow

JB

On 11 May 2014 02:27, Thomas Nichols notifications@github.com wrote:

Let me record what I think is the lineage.

• We started with CoordinateSpace to record something like what the
  NIFTI header and SPM's volume structure holds (basic information on the
  array, and voxel-world-mapping).
• The coordinateSystem was an attribute of a CoordinateSpace, giving
  the canonical meaning to world space. We propose now to rename this
  referenceSpace (Please ignore my first letter capitalizations as they
  may all be wrong). We re-naming also to avoid confusion with NiPy's
  CoordinateSystem.

I've studied the NiPy API's Coord* functionshttp://nipy.org/nipy/stable/api/index.html,
and it seems that our CoordinateSystem has everything there except the
named axes. As we generally have no idea about axis except from a atlas
space, I think names should live in coordinateSystem (but don't feel too
strongly on this).

So! My proposal is that we use the existing CoordinateSpace and the
renamed and revamped referenceSpace and call it it day.

@jbpoline https://github.com/jbpoline : What do you think?

—
Reply to this email directly or view it on GitHubhttps://github.com/ni-/ni-dm/issues/52#issuecomment-42766052
.

[cmaumet]

Suggested by @jbpoline, rename StandardizedSpace in CustomSpace.

How do we store, I know this was aligned to a particular space but I don't know which one.

[cmaumet]

A beginning of implementation is now available in #123, let's continue the discussion over there.