Limitations of BIDS SpatialRef system for surface data

,
1

Hi all,

I’ve been thinking about how to best translate outputs of the Human Connectome Project pipelines into BIDS format, and I’ve come across some issues that point to limitations of the SpatialRef metadata system for dealing with surface data and coordinate systems.

As an example, these outputs include surfaces in fsnative space, and surfaces defining the fsLR template, both of which have straightforward spatial references. But they also include files like the fsnative space pial surface, resampled to the fsLR coordinate system, at some mesh resolution. In this case, the “spatial reference frame” of the surface (ie, the mapping of surface coordinates to a volumetric space and T1 image) is still fsnative, but the coordinates used to define the surface correspond to fsLR. How would this be specified in the BIDS filename/metadata for this surface? Using the density field to specify the coordinate system doesn’t work, because fsLR can still be sampled at multiple densities. The desc field could be used, but this seems inappropriate for such an important property, relating to the definition of the surface coordinate system, and determining correspondence with metric/label images.

This brings up a related issue about metadata for metric and label gifti files. These files are only tied to a coordinate system, not to a specific spatial alignment of that coordinate system. IE, I can attach a metric in fsLR coordinates to either the fsLR pial/etc surface, or to a surface in fsnative space with fsLR coordinates, etc. Since there isn’t an intrinsic spatial interpretation of the coordinates in these files, without attaching them to a surface file, it’s not clear that we should describe these files with a “spatial reference” in the way that we do volume and surface files.

This leads to a straightforward suggestion for a fix, which is to split surface template definition into two fields: spatial reference and coordinate reference. The coordinate reference would specify the topological interpretation of the coordinate system, while the spatial reference would specify the embedding of those coordinates within a specific 3D spatial frame. Surface files would have both a spatial and coordinate reference, while metric/label files would only have a coordinate reference. This would better reflect the metadata needed to interpret each file type, and would enable a natural naming convention for all of the HCP pipeline output surfaces.

Curious what you guys think about these issues and potential solution. It looks like there are some similar ideas on the most recent BIDS RC14 document, although maybe not exactly this.

cc @oesteban, @effigies, @franklin, @satra

cheers,

Ben

2

Thanks for this! BIDS has evolved faster and steadier when clear use-cases supported decisions. So this is definitely helpful to advance the specifications.

This seems to mean that vertices of fsnative pial surface are mapped on to the fsLR corresponding surface. However, the key is that “resampled to” - that makes me think (coinciding with my first guess about what could be going on) that you have some data sampled on some standard surface of fsLR. And being HCP Pipelines outputs, I would adventure that MSM registration was performed, finding the alignment between fsLR and fsnative, and using that transform to project the coordinates of the vertices in the fsLR surface on to fsnative (and then use FreeSurfer internals) to map those to the volume, sample (=interpolate) and compose the CIFTI2 output.

If this is the case, you should have all the information you need with the density of fsLR used, as this space defines the volumetric coordinate system in full (this may not be true if you build some kind of Frankestein CIFTI2 non-conformant to HCP’s grayordinates system, as fMRIPrep used to do some versions ago).

We’ve struggled (an probably continue) with this issue in the past. I agree with your suggestion that two “references” could be provided. But, differing from your proposal, I think the concepts are “coordinate system of reference” and “sampling reference”.

The coordinate system of reference is the subject’s “scanner” coordinates or some standard “space”, which necessarily refers to some volumetric template (e.g., one MNI). I honestly don’t think there could be anything else.

Then, the second concept is the sampling reference which tells you where (spatially speaking) you are sampling, and the manifold supporting the sampling (surface or grid). For templates, the sampling reference can be resolved with the resolution entity. For surfaces, you have density. As long as you have a standard reference for resolutions and densitys, space will encode the reference for coordinates and resolution/density map to the sampling locations.

This approach is problematic when you don’t use standard sampling references (e.g., you take the highest fsLR resolution and regrid the surfaces to match some particular density), especially if you match your density to one already existing in your reference space (e.g., you create an additional 91k density IN fsLR - in other words, your flavor of fsLR is indeed spatially aligned with fsLR, but your vertices are somewhere else on the same surface).

I acknowledge that the current specs are not wonderful to designate these kinds of data, but I believe should be sufficient to represent HCP Pipelines outputs.

Please let me know if I managed to explain my opinion, and please point me to some example file from one subject to be more concrete on how I believe that could be encoded.

3

Hi Oscar,

Thanks for the response. Let me state a more concrete question. I’m trying to come up with a BIDS naming convention for four surfaces (per hemisphere) from the HCP pipeline outputs, where SUB is the subject’s ID:

SUB/MNINonLinear/fsaverage_LR32k/SUB.L.midthickness.32k_fs_LR.surf.gii
SUB/MNINonLinear/Native/SUB.L.midthickness.native.surf.gii
SUB/T1w/fsaverage_LR32k/SUB.L.midthickness.32k_fs_LR.surf.gii
SUB/T1w/Native/SUB.L.midthickness.native.surf.gii

These are all representations of a given subject’s midthickness surface, which differ in two ways: 1) which volumetric image (MNI or native anatomical) they are in spatial correspondence with, and 2) which surface coordinate mesh (Freesurfer native or fsLR 32k) they are sampled with.

In terms of correspondence with volumes, the surfaces in T1w are in volumetric correspondence with the subject’s native T1w/T2w images. The surfaces in MNINonLinear are in volumetric correspondence with the MNI152NLin6ASym template; they’re derived by applying a FNIRT-based volumetric warp to the subject’s surface reconstructions. (Note one further wrinkle: in terms of “coordinate system of reference,” using your term, all of the coordinates are in MNI space. This is because the anatomical images have been volumetrically aligned with MNI space via rigid-body transformation prior to freesurfer reconstruction, at the ACPC-alignment step. So even the coordinates defining the native volumes are MNI coordinates - although the thought experiment would still apply if that weren’t the case.)

In terms of surface-based coordinate systems, the images in the Native folder are sampled at the resolution used by Freesurfer (~150k), while the images in fsaverage_LR32k are resampled to fsLR coordinates, using roughly the procedure you described (with MSMSulc to align fsLR and fsnative coordinates).

Basically, the question is how to name the images. More specifically, the issue with the current convention is that both of the fsLR-resampled surfaces could be described as space-fsLR_den-32k, but they differ in a critical respect: one is in correspondence with an MNI template brain, while the other is not (despite having coordinates defined by MNI space). I’m interested in resampling and analyzing fMRI data in T1w/fsaverage_LR32k surface space with subcortical volumetric coordinates defined based on an individual subject’s anatomical image, so am particularly keen on coming up with a meaningful naming scheme for that surface.

4

Just bumping this thread, as I’m still struggling with this issue, and curious if anyone has thoughts on how to meaningfully name HCP pipeline outputs in BIDS convention.