DICOM:Database - Revision history

Pieper: /* Considerations */

2010-03-18T19:47:56Z

Considerations

Millerjv: /* Considerations */

2010-03-18T13:24:26Z

Considerations

Pieper: /* Example Data */

2010-03-14T15:26:30Z

Example Data

Lorensen: /* Considerations */

2010-03-09T18:47:00Z

Considerations

Lorensen at 18:27, 9 March 2010

2010-03-09T18:27:37Z

Pieper: /* Considerations */

2010-03-09T17:07:31Z

Considerations

Pieper at 17:02, 9 March 2010

2010-03-09T17:02:10Z

Pieper: /* Considerations */

2010-03-09T15:22:54Z

Considerations

Pieper: /* Example Data */

2010-03-09T15:05:39Z

Example Data

Pieper at 14:56, 9 March 2010

2010-03-09T14:56:53Z

← Older revision		Revision as of 19:47, 18 March 2010
Line 27:		Line 27:

	* Jim suggests that the image table hold information about the resolution, pixel size, (or field of view), coordinate frame (imagepositionpatient, imageorientationpatient), acquisition time, etc. as well as an offset into the file for the start of the pixel data. The goal should be that once the data had been entered into the database we never have to use a dicom parser again on that subject. Unless we are looking to pull out a very special tag. We should probably put some summary information up at the series level. You can't always do that so maybe the series table needs a column which indicates whether the whole series is homogeneous.		* Jim suggests that the image table hold information about the resolution, pixel size, (or field of view), coordinate frame (imagepositionpatient, imageorientationpatient), acquisition time, etc. as well as an offset into the file for the start of the pixel data. The goal should be that once the data had been entered into the database we never have to use a dicom parser again on that subject. Unless we are looking to pull out a very special tag. We should probably put some summary information up at the series level. You can't always do that so maybe the series table needs a column which indicates whether the whole series is homogeneous.
		+	** Steve agrees with Jim, but suggests that maybe we have multiple databases: a central database with minimal information to point sort out patients/studies/series and then another database file per study that has the detailed information. This per-study database file could be use for the fast loading without making the central database file grow too big.

← Older revision		Revision as of 13:24, 18 March 2010
Line 25:		Line 25:

	* Bill proposes [[Slicer3/DICOM import mechanism\|a background DICOM import mechanism]].		* Bill proposes [[Slicer3/DICOM import mechanism\|a background DICOM import mechanism]].
		+
		+	* Jim suggests that the image table hold information about the resolution, pixel size, (or field of view), coordinate frame (imagepositionpatient, imageorientationpatient), acquisition time, etc. as well as an offset into the file for the start of the pixel data. The goal should be that once the data had been entered into the database we never have to use a dicom parser again on that subject. Unless we are looking to pull out a very special tag. We should probably put some summary information up at the series level. You can't always do that so maybe the series table needs a column which indicates whether the whole series is homogeneous.

@@ Line 9: / Line 9: @@
 == Example Data ==
-* [http://github.com/pieper/CTK/blob/master/Libs/DICOM/Resources/dicom-schema.sql MITK DICOM Schema]
+* [http://github.com/pieper/CTK/blob/master/Libs/DICOM/Core/Resources/dicom-schema.sql MITK DICOM Schema]
-* [http://github.com/pieper/CTK/blob/master/Libs/DICOM/Resources/dicom-sample.sql Dump of example database created with schema above]
+* [http://github.com/pieper/CTK/blob/master/Libs/DICOM/Core/Resources/dicom-sample.sql Dump of example database created with schema above]
 * [[file:dicom-database-examples-2010-03-09.zip| Sample DICOM data used to create the database dump]]
 * [[Slicer3/strawman DICOM Schema|Lorensen's strawman sqlite DICOM schema]]
 == Considerations ==

← Older revision		Revision as of 18:47, 9 March 2010
Line 23:		Line 23:

	* Marco plans to contribute a cleaned up version of the MITK code to the [http://github.com/pieper/CTK CTK git repository].		* Marco plans to contribute a cleaned up version of the MITK code to the [http://github.com/pieper/CTK CTK git repository].
		+
		+	* Bill proposes [[Slicer3/DICOM import mechanism\|a background DICOM import mechanism]].

@@ Line 12: / Line 12: @@
 * [http://github.com/pieper/CTK/blob/master/Libs/DICOM/Resources/dicom-sample.sql Dump of example database created with schema above]
 * [[file:dicom-database-examples-2010-03-09.zip| Sample DICOM data used to create the database dump]]
 == Considerations ==

← Older revision		Revision as of 17:07, 9 March 2010
Line 20:		Line 20:

	* Eventually we could create an ITK IO Factory plugin reader that an read when given an SQLite filename and a query string that specifies a volume. With something like: "/tmp/dicom.db:SeriesUID=1.2.3...." If the SQL database kept the width, height, and pixel data offset then the files could be read quickly without re-parsing.		* Eventually we could create an ITK IO Factory plugin reader that an read when given an SQLite filename and a query string that specifies a volume. With something like: "/tmp/dicom.db:SeriesUID=1.2.3...." If the SQL database kept the width, height, and pixel data offset then the files could be read quickly without re-parsing.
		+
		+	* Marco plans to contribute a cleaned up version of the MITK code to the [http://github.com/pieper/CTK CTK git repository].

@@ Line 5: / Line 5: @@
 Bill started [http://massmail.spl.harvard.edu/public-archives/slicer-devel/2010/004323.html a thread on the slicer-devel mailing list] about improving dicom parsing performance.  [http://massmail.spl.harvard.edu/public-archives/slicer-devel/2010/004364.html This message] includes a sample sql database schema as an attachment.
-A similar approach has been followed as part of the [http://mitk.org MITK project] using [http://dicom.offis.de DCMTK] to fill an [http://sqlite.org SQLite] database.
+At the [http://www.na-mic.org/Wiki/index.php/Events:CTK-Pre-Hackfest-2010 CTK meeting], Marco Nolden showed a similar approach has been followed as part of the [http://mitk.org MITK project] using [http://dicom.offis.de DCMTK] to fill an [http://sqlite.org SQLite] database.
 == Example Data ==

← Older revision		Revision as of 15:22, 9 March 2010
Line 14:		Line 14:

	== Considerations ==		== Considerations ==
		+
		+	* It would be ideal if the database schema was standardized and could be used with any DICOM toolkit (GDCM and/or DCMTK).
		+
		+	* The MITK schema is nice because it uses the standard DICOM field names for the columns, for example PatientsUID, ModalitiesInStudy, etc).
		+
		+	* Eventually we could create an ITK IO Factory plugin reader that an read when given an SQLite filename and a query string that specifies a volume. With something like: "/tmp/dicom.db:SeriesUID=1.2.3...." If the SQL database kept the width, height, and pixel data offset then the files could be read quickly without re-parsing.

← Older revision		Revision as of 15:05, 9 March 2010
Line 8:		Line 8:

	== Example Data ==		== Example Data ==
		+
		+	* [http://github.com/pieper/CTK/blob/master/Libs/DICOM/Resources/dicom-schema.sql MITK DICOM Schema]
		+	* [http://github.com/pieper/CTK/blob/master/Libs/DICOM/Resources/dicom-sample.sql Dump of example database created with schema above]
		+	* [[file:dicom-database-examples-2010-03-09.zip\| Sample DICOM data used to create the database dump]]

	== Considerations ==		== Considerations ==

← Older revision		Revision as of 14:56, 9 March 2010
Line 1:		Line 1:
	Local databases to organize DICOM header information are often used in medical image applications and workstations. This page is used to organize information and examples.		Local databases to organize DICOM header information are often used in medical image applications and workstations. This page is used to organize information and examples.
		+
		+	== History ==
		+
		+	Bill started [http://massmail.spl.harvard.edu/public-archives/slicer-devel/2010/004323.html a thread on the slicer-devel mailing list] about improving dicom parsing performance. [http://massmail.spl.harvard.edu/public-archives/slicer-devel/2010/004364.html This message] includes a sample sql database schema as an attachment.
		+
		+	A similar approach has been followed as part of the [http://mitk.org MITK project] using [http://dicom.offis.de DCMTK] to fill an [http://sqlite.org SQLite] database.
		+
		+	== Example Data ==
		+
		+	== Considerations ==