MRI Repository/Design Decisions

From VrlWiki
Revision as of 14:34, 8 July 2010 by Brad Berg (talk | contribs) (New page: This page is being used to work through open issues in the MRI Repository * Compression * File Using (losslessly) compressed NIfTI files, a single scan of an individual totals a little u...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page is being used to work through open issues in the MRI Repository

  • Compression
  • File Using (losslessly) compressed NIfTI files, a single scan of an individual

totals a little under 90MB. If we were instead to post DICOMs, I think we would end up closer to 350MB per scan but that could also be compressed at a pretty great ratio. Offering both formats would be ideal; with compressed DICOMs, I think the total size per scan would be about 275MB, plus a little extra for metadata. Thus far we have on the order of 200 patients scanned from various studies, and so the database should be able to accommodate something around that scale: 50GB baseline, with the possibility to expand by an order of magnitude.

It would be nice to offer coregistered and even atlas-registered data, following Win's pipeline, but there are tradeoffs to that. Whatever happens, the untouched fresh-off-the-scanner data must be made available. Any choices we make about further derived forms of the data should be applied to all datasets --- that is, if we offer coregistered data for one patient, we must offer coregistered data for all patients. Any registered data should be accompanied by its registration matrices.

The database should be searchable and sliceable --- that is, a user should be able to get all scans for a certain patient, or a certain age range, or a certain disease state. We will likely be posting other types of scans besides diffusion MRI (for example, T1-weighted MRI), so the type of scan would be another search index.

We would be hard-pressed to design a static website that meets these