initial pass at a single cerebellar atlas

[satra]

initial example of a single cerebellar atlas. includes the notebook for conversion.

Notebook here

[satra]

it turns out that for this atlas, the anatomy and the labels only align in world space. i.e. there is no voxel to voxel mapping. the atlas is a reduced FOV image only containing the cerebellum. also because of the tool used to label the cerebellum the voxel sizes are sub mm.

what are people's thoughts on how to include the following information.

1. the T1 file containing the entire brain
2. the information saying that these two are only related in world space.

[mhalle]

We have done some thinking about providing a transformation between atlases that might be useful here. I recall that we explicitly deferred coordinate system description in Boston.

In our HAWG/JSON-LD based atlases at the SPL, we propose a "CoordinateFrame" node type. We would like to avoid creating a new coordinate system description (as we also discussed in Boston) while allowing for the possibility that simple coordinate frame descriptions might be useful in the future.

So, we propose a "DataSourceCoordinateFrame" node subtype that contains a reference to a DataSource node. Effectively, the new node says, "use the coordinate frame of this data source", on the assumption that any reader that can parse the data source also by definition needs to be able to read the coordinate system information. Any additional information needed to specify a specific coordinate frame in the data source can be described in the DataSourceCoordinateFrame node.

Once we have these CoordinateFrame nodes, any other node in the atlas description that specifies coordinates or geometric information can contain a reference to a CoordinateFrame to provide meaning to those coordinates. Doing so should completely eliminate coordinate space ambiguity.

So with CoordinateFrame nodes, multiple coordinate systems can exist in the same atlas. However, there needs to be a way to get back and forth between different CoordinateFrames. That requires some sort of Transform node. We haven't finalized exactly how Transforms would work. One way would be to use a Transform to wrap an existing CoordinateFrame, producing a derived one.

In the case you describe, we need both CoordinateFrame transforms (possibly the identity transform) and spatial extents (different for the two volumes). I think we could make that work, since it is a subset of the more general problem.

Comments appreciated!