Freesurfer support


We would like to review/refactor our support for freesurfer data. This includes rethinking how the files are stored in the archive space. It also involves reviewing/redesigning the schema types we've used to represent freesurfer data.

Regarding File Referencing

Option 1: Reference all files in catalogs

This would involve having a catalog entry for every file in the freesurfer results. This would lead to a LARGE catalog document, but would be the expected (supported) method for the current XNAT release (1.4).

Option 2: Reference some files in catalogs

This is the way we've been doing it. To continue down this road, we would need to add seamless support to XNAT for accessing unreferenced files every where you can download referenced files.

Option 3: Zip files into single resource

This may be particularly appropriate for the freesurfer dataset. This would involve zipping the entire freesurfer results and referencing the zip from the catalog. This would allow us to 'reference' all of the files without referencing each file individually. In 1.4, this is supported be adding the catalog as an entry.

<?xml version="1.0" encoding="UTF-8"?>
<cat:Catalog>
    <cat:entries>
        <cat:entry URI="./freesurfer.zip"/>
    </cat:entries>
</cat:Catalog>
 
In 1.5, we would like to increase support for zip access. This is an off-shoot of the support for multiframe data. The idea is that you could reference specific entries out of the zip (to allow file level tags). In this model, the zip file would be referenced via a new catalog extension type. Entries defined within that catalog would allow tags and details about individual files within the zip. The entries would be supplemental to the manifest available from the zip, so they would not be required. Doing a REST GET listing on the zip would return a list of all of the files (not just the referenced entries). It will look something like this...

<?xml version="1.0" encoding="UTF-8"?>
<cat:Catalog URI="./freesurfer.zip" xsi:type="cat:ZipCatalog">
    <cat:entries>
        <cat:entry URI="mri/brainmask.mgz" format="MGZ" content="brain mask"/>
        <cat:entry URI="mri/aseg_with_cc.mgz" format="MGZ" content="segmentation volume"/>
        <cat:entry URI="mri/norm.mgz" format="MGZ" content="in volume"/>
        <cat:entry URI="stats/aseg.stats" format="FS_STATS" content="$stats_type stats"/>
    </cat:entries>
</cat:Catalog>
For a bit more information on what I was thinking here, see the feature page for Enhanced ZIP support.


Option 4: Reference no files

This is a radical idea I've been starting to consider. However, I think it is still a few XNAT versions away (probably part of moving to File Server). The idea would be, if you put the files in the right place, then you wouldn't need to create a catalog at all (unless you need to specifically tag a few files). XNAT could generate a catalog on request based on the file system contents. I'm very interested in this approach... for reasons I will decide on later.

Regarding Schema design

Goals:
  • A single assessment should be used to reference all of the freesurfer data. No APARC assessor or ASEG assessor. Just a freesurfer assessor.
  • All freesurfer data should be referenced from within the freesurfer assessment (Nothing in the MR resources). This should be obvious once we have a single freesurfer assessor.