MRI Repository/Brown Web Site - Revision history

Jadrian Miles: Brown Web Site moved to MRI Repository/Brown Web Site: This is a sub-page.

2010-09-07T13:41:07Z

Brown Web Site moved to MRI Repository/Brown Web Site: This is a sub-page.

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

Brad Berg at 14:37, 8 July 2010

2010-07-08T14:37:55Z

← Older revision		Revision as of 14:37, 8 July 2010
Line 11:		Line 11:

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


	* Patient Privacy		* Patient Privacy

Brad Berg at 14:37, 8 July 2010

2010-07-08T14:37:34Z

← Older revision		Revision as of 14:37, 8 July 2010
Line 8:		Line 8:
	* Special consideration for the size of the database.		* Special consideration for the size of the database.

	~~: 1GB to 1TB range.~~		: Primarily read only access with new data added as available.
	: Primarily read only with new data added as available.
	: 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		: 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.
	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.

	* Patient Privacy		* Patient Privacy

Brad Berg at 14:36, 8 July 2010

2010-07-08T14:36:44Z

← Older revision		Revision as of 14:36, 8 July 2010
Line 10:		Line 10:
	: 1GB to 1TB range.		: 1GB to 1TB range.
	: Primarily read only with new data added as available.		: Primarily read only with new data added as available.
			: 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.

	* Patient Privacy		* Patient Privacy

Brad Berg at 14:21, 8 July 2010

2010-07-08T14:21:11Z

← Older revision		Revision as of 14:21, 8 July 2010
Line 29:		Line 29:
	* Data compression		* Data compression

	: On the fly compression.		: On the fly compression? If available.
	: Lossless compression? Probably required.		: Lossless compression? Probably required.
	~~: Off the shelf or static Huffman?~~

Brad Berg at 14:20, 8 July 2010

2010-07-08T14:20:16Z

← Older revision		Revision as of 14:20, 8 July 2010
Line 15:		Line 15:

	: Using Patient IDs		: Using Patient IDs
	:: ~~Davis takes~~ responsibility for privacy issues.		:: David is taking responsibility for privacy issues.
	:: Is there a decoding mechanism?		:: Is there a decoding mechanism?

Brad Berg: New page: The ticket [CS #169372] is assigned to John Bazik. * The repository URL needs to survive all our careers. : JSB: I don't expire urls. I go to great pains to maintain old links, even fo...

2010-07-08T14:19:51Z

New page: The ticket [CS #169372] is assigned to John Bazik. * The repository URL needs to survive all our careers. : JSB: I don't expire urls. I go to great pains to maintain old links, even fo...

New page

The ticket [CS #169372] is assigned to John Bazik.

* The repository URL needs to survive all our careers.

: JSB: I don't expire urls. I go to great pains to maintain old links, even for trivial stuff.

* Special consideration for the size of the database.

: 1GB to 1TB range.
: Primarily read only with new data added as available.

* Patient Privacy

: Using Patient IDs
:: Davis takes responsibility for privacy issues.
:: Is there a decoding mechanism?

* Transfer mechanism

: Must be able to transfer large data blocks.
: Recover and resume from network disruptions on both ends.
: Encryption? Probably not.
: Password protection?

* Data compression

: On the fly compression.
: Lossless compression? Probably required.
: Off the shelf or static Huffman?