MRI Repository/Design Decisions - Revision history

Jadrian Miles: Design Decisions moved to MRI Repository/Design Decisions: This is a sub-page.

2010-09-07T13:40:37Z

Design Decisions moved to MRI Repository/Design Decisions: This is a sub-page.

← Older revision	Revision as of 13:40, 7 September 2010
(No difference)

Brad Berg at 15:39, 8 July 2010

2010-07-08T15:39:07Z

← Older revision		Revision as of 15:39, 8 July 2010
Line 49:		Line 49:
	:: ? Python		:: ? Python
	:: ? Perl		:: ? Perl
			::: - Perl is a hack
	:: ? Java		:: ? Java

Brad Berg at 15:38, 8 July 2010

2010-07-08T15:38:31Z

← Older revision		Revision as of 15:38, 8 July 2010
Line 52:		Line 52:

	* Data management		* Data management

			: MRI's are currently in: <code>/data/graphics/mri/*/</code>
			: ? Other MIR's

	: I foresee some sort of unique ID for each scan (it need not be an obfuscated one!		: I foresee some sort of unique ID for each scan (it need not be an obfuscated one!

Brad Berg at 14:58, 8 July 2010

2010-07-08T14:58:23Z

@@ Line 1: / Line 1: @@
 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
+: ? Compress on the disk
-totals a little under 90MB.  If we were instead to post DICOMs, I think we
+:: - Overhead to instrument all software with decompressors.
-would end up closer to 350MB per scan but that could also be compressed at a
+:: ? Compressed files may be pre-staged for downloading.
-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
+: ? Compression on download
-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
+: ? Compression mechanism
-around that scale: 50GB baseline, with the possibility to expand by an order of
+:: ? Support multiple compressors
-magnitude.
+:: ? Support one compressor
-It would be nice to offer coregistered and even atlas-registered data,
+:: ? A standard format like &lt;patient ID&gt;_&lt;scan date&gt;_&lt;scan type&gt;_&lt;scan repetition&gt;
-The database should be searchable and sliceable --- that is, a user should be
+:: ? A flat pool of files named according to the ID, and an SQL database that matches each ID to its values for the various search indices.
-We would be hard-pressed to design a static website that meets these
+: The website would ideally be a pleasantly-designed interface to this database.

Brad Berg: 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...

2010-07-08T14:34:02Z

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...

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 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