Switching to .json for Markup files: any convergence with BIDS?

Development
, ,
1

This is a continuation of discussion from the following thread MarkupsLine .fcsv loads as MarkupsFiducials

@lassoan brought up the consideration of switching to .json for handling Markup files in Slicer5. I think the simple answer from the perspective of the AFIDs project is that we will adapt to whatever specs are decided on for Slicer5, but ultimately we have interest in easily being able to convert between Slicer’s Markup file format and one that would be compatible with the Brain Imaging Data Structure (BIDS) specifications.

This may be a good time to try to determine if there is a point of convergence between the needs of both Slicer and BIDS for handling coordinates in .json files that might eliminate the need for any conversion tool. However, this can get complicated if we are looking to decide on .json fields that both Slicer and BIDS communities can agree on.

Compared with other aspects of the BIDS specification which are more mature, representation of coordinates remains a work in progress but is of interest to the community for different applications. The most recent version describing “Coordinate Systems” in the BIDS specification (v1.4.0) is here.

There have been different modality specific implementations (the one I’m most familiar with being iEEG) where the proposed solution is to use a paired set of files .json and .tsv to specify electrode locations: see https://www.nature.com/articles/s41597-019-0105-7#Sec4 and Figure 1e and 1f, which I’ve included. Having two files for Markups would likely be quite cumbersome in the Slicer environment.

Screen Shot 2020-06-11 at 11 28 55 PM
Screen Shot 2020-06-11 at 11 28 55 PM1928×590

I’d appreciate your thoughts and can loop in members of the BIDS community if interested. I also acknowledge that the Slicer user base likely has different needs than the BIDS/neuroimaging base, so having a converter tool as a go-between may be inevitable.

2

This two-file format does not seem very appealing for many reasons, including:

  • two files for a single markup would not be practical, especially for simple markups, such as lines or angles, which only contains a few points
  • even two files could not store the information we need (display properties, measurements, etc.) - would those all be stored in additional files? It would mean that a single line annotation would require at least 4 files (point end positions, coordinate system, display properties, measurement result)
  • tsv files are very slow to parse and there is no universally accepted standards for their interpretation (how to encode/escape special characters and separators, basic data types, what makes a header valid, etc.)
  • there is no standard schema for tsv files
  • we cannot rely on folder structure and filenames to establish links between data sets, as it would be just too rigid and fragile (instead we rather use UIDs for cross-references between information objects: MRML node IDs and DICOM-compliant UIDs)

To improve interoperability between BIDS and Slicer, probably the best would be to implement a BIDS importer/exporter module. We have some initial work here.

3

Agree with your assessment. I am also starting to wonder if the coordinate representation in BIDS-iEEG would be better as a single file. I’ll consider proposing that change at some point once I’ve had a chance to think about it more.

For now, let’s just assume that BIDS and Slicer5 representations of points in .json will develop independently and require a converter tool to go between formats.

1 Like