NAMIC Wiki - User contributions [en]

2010 Project Week DICOM supplement 145

2010-06-25T14:06:51Z

Mathieu: /* Standard support for discrete 2 and 3 manifold storage in ITK */

__NOTOC__
<gallery>
Image:PW-MIT2010.png|[[2010_Summer_Project_Week#Projects|Projects List]]
</gallery>

==Key Investigators==
* Mathieu Malaterre: CoSMo Software
* Alex. Gouaillard: CoSMo SOftware, A*STAR
* Luis Ibanez: Kitware Inc.

==Project==
DICOM Supplement 145 provide a way to go over the 32bits limits and allow storing of large images. We propose to implement this specification.
In addition, we would implement DICOM specification for JPEG 2000 Part 2 Multi-component Image Compression. This portion of the standard provides higher
compression ratio for storing multicomponent images.
Finally by implementing DICOM supplement 132, we would provides support for storing of surfaces and 3D volumes, as an addition to the 2D RTSTRUCT.

=== Standard support for Large multicomponent images in ITK ===
DICOM currently defines Image IODs by storing the rows and columns as unsigned short
integer. This means that an image can only be at most of size 2^16 * 2^16 pixels.
This is a limitation for Microscopy Images as , for example, typical Whole Slice Images an be 60,000 * 80,000 pixels. Since images are generally stored with 24-bit color
pixels, this means WSI can go up to 15Gb. Confocal Microscopy Images add one additional
dimension, and are today already capable of acquiring 24 channels. They are reported to need up
to petabytes.
For this reason DICOM Supplement 145 defines a way to store images into multiple
DICOM files providing a mean to work around this 32bits limitation of DICOM.
By implementing this Supplement (which is still in Ballot), we would provide to the
ITK community a proof of concept and allow people to start saving larges images using DICOM.
This would allow the re-using of technologies and prevent people from re-inventing the wheel
and start using a new file format to exchange medical image (second system effect).

=== Standard support for multicomponent images compression in ITK ===
Microscopy Images, on top of being larger sometimes by several orders of magnitudes from medical images, are also multi-component. Even though ITK handle multicomponent images per say, by defining the right pixel type, nothing is available today for the storage and compression of images that would have more than 3 channels (RGB). Since 2001, the DICOM standard allows JPEG 2000 compression. GDCM 2.x has supported a portion of the standard by providing an API to allow transfer syntax such as JPEG 2000 Image Compression (1.2.840.10008.1.2.4.90 and 1.2.840.10008.1.2.4.91). However the standard also includes JPEG 2000 Part 2 Multi-component Image Compression (1.2.840.10008.1.2.4.92 and 1.2.840.10008.1.2.4.93). The latter has never made into GDCM / ITK, or any other open source DICOM toolkit, since as quoted from the presentation: “Image Compression Refresher – JPEG 2000 and 3D, David Clunie”: the compression gain was modest (using lossless compression). We see now an opportunity that this compression can make it into GDCM / ITK since microscopy images would perfectly fit into the original design of the compression (ISO/IEC 15444-2:2003 Annex J). This would ease the dissemination of large dataset by reusing standard compression techniques, since this would greatly reduce the size of those file datasets. This will be particularly useful for microscopic images. At the time of writing no other open-source DICOM toolkit offer this compression algorithm.

=== Standard support for discrete 2 and 3 manifold storage in ITK ===
From its early design, ITK has always offered some n-dimensional n-manifold (polygonal meshes) support through the itk::Mesh class. However at the time of writing of this proposal, there is still no official way to read or write those meshes from and to a filesystem in ITK. Only an hybrid solution is available in Insight Applications. However it implies a dependency to the entire VTK library which is an overkill most of the time.
Thanks to the work on itk::QuadEdgeMesh some progress have been made toward that goal. The Review directory surrently holds a very simple VTK PolyData reader and writer. However, it only supports legacy vtk files using ASCII encoding. For its defense, this implementation was only made for regression testing and illustration of the filters usage.
We are proposing here to fill this gap in the ITK toolkit and implement DICOM's Supplement 132, part of the standard since 2008, which would add surfaces and volumes meshes (2 and 3 manifolds) storage capacity to GDCM /ITK. This would add support for surfaces and volume (2 and 3 manifolds in n dimensional space, see supplemental material annex).
We suggest 2 different options. The first option would allow for storage of itk::QuadEdgeMesh as a DICOM file. The second options would allow for storage of an itk::Mesh as a DICOM file. Of course reading the corresponding structures from a DICOM file would also be provided.
As an illustration, we make a clear distinction in what itk::QuadEdgeMesh handles and what itk::Mesh can handle. Both 2 and 3 manifold objects are handled in the DICOM standard.
We do anticipate a large portion of this task to be validation testing. Since there are no other serialization mechanism available in ITK, we will need to setup an hybrid system with VTK to perform validation on the dataset written (a 3D VTK mesh will be used as input for the tests). For this we would be re-using code from InsightApplications/Auxiliary/vtk/vtk2itk.cxx.

<div style="margin: 20px;">
<div style="width: 27%; float: left; padding-right: 3%;">

<h3>Objective</h3>
The objectives of the project week is to share with the community and make a list of persons interested and of corresponding efforts before we start implementing. Typically at the end of the week we would like to have identified existing parts, ongoing effort and have a roadmap available possibly with other groups joining in depending on needs, manpower and expertise.

</div>
<div style="width: 27%; float: left; padding-right: 3%;">

<h3>Approach, Plan</h3>
'''1.''' Item #1: Compare existing technologies: HDF5, DICOM, JPEG2000, TIFF (XMP)

'''2.''' Item #2: Identify technologies in ITK: openjpeg v1 which does not support tiles (required for streaming)

'''3.''' Item #3: Identify group which would need this technology: maybe CTK ?

</div>
<div style="width: 40%; float: left;">

<h3>Progress</h3>

'''*''' Worked with Kishore for ITK/JPEG 2000 reader. Code review / Made it compile

'''*''' Sync with upstream openjpeg team: there are 400 regression tests now !

'''*''' Need to synchronize effort with GDCM 2.x and OpenJPEG v2 update. Prepare patch for GDCM 2.x to use openjpeg v2.

'''*''' Worked with GoFigure2 team to identify the need:
** passing algorithm more than passing data.
** image data
** very large image 4D
** mesh based segmentation (2d / 3d mesh)
** annotations (label)

'''*''' XMP technogoly is based on XML, which imply ASCII serialization (poor performance, very verbose).

</div>
</div>

<div style="width: 97%; float: left;">

==Delivery Mechanism==

This work will be delivered to the NA-MIC Kit as a

* ITK Module
* Other: GDCM extension (gdcm is included in ITK)

==References==
*the official DICOM Standard Proposal [ftp://medical.nema.org/medical/dicom/supps/sup145_09.pdf here]

</div>

2010 Project Week DICOM supplement 145

2010-06-25T13:53:41Z

Mathieu: /* Standard support for discrete 2 and 3 manifold storage in ITK */

__NOTOC__
<gallery>
Image:PW-MIT2010.png|[[2010_Summer_Project_Week#Projects|Projects List]]
</gallery>

==Key Investigators==
* Mathieu Malaterre: CoSMo Software
* Alex. Gouaillard: CoSMo SOftware, A*STAR
* Luis Ibanez: Kitware Inc.

==Project==
DICOM Supplement 145 provide a way to go over the 32bits limits and allow storing of large images. We propose to implement this specification.
In addition, we would implement DICOM specification for JPEG 2000 Part 2 Multi-component Image Compression. This portion of the standard provides higher
compression ratio for storing multicomponent images.
Finally by implementing DICOM supplement 132, we would provides support for storing of surfaces and 3D volumes, as an addition to the 2D RTSTRUCT.

=== Standard support for Large multicomponent images in ITK ===
DICOM currently defines Image IODs by storing the rows and columns as unsigned short
integer. This means that an image can only be at most of size 2^16 * 2^16 pixels.
This is a limitation for Microscopy Images as , for example, typical Whole Slice Images an be 60,000 * 80,000 pixels. Since images are generally stored with 24-bit color
pixels, this means WSI can go up to 15Gb. Confocal Microscopy Images add one additional
dimension, and are today already capable of acquiring 24 channels. They are reported to need up
to petabytes.
For this reason DICOM Supplement 145 defines a way to store images into multiple
DICOM files providing a mean to work around this 32bits limitation of DICOM.
By implementing this Supplement (which is still in Ballot), we would provide to the
ITK community a proof of concept and allow people to start saving larges images using DICOM.
This would allow the re-using of technologies and prevent people from re-inventing the wheel
and start using a new file format to exchange medical image (second system effect).

=== Standard support for multicomponent images compression in ITK ===
Microscopy Images, on top of being larger sometimes by several orders of magnitudes from medical images, are also multi-component. Even though ITK handle multicomponent images per say, by defining the right pixel type, nothing is available today for the storage and compression of images that would have more than 3 channels (RGB). Since 2001, the DICOM standard allows JPEG 2000 compression. GDCM 2.x has supported a portion of the standard by providing an API to allow transfer syntax such as JPEG 2000 Image Compression (1.2.840.10008.1.2.4.90 and 1.2.840.10008.1.2.4.91). However the standard also includes JPEG 2000 Part 2 Multi-component Image Compression (1.2.840.10008.1.2.4.92 and 1.2.840.10008.1.2.4.93). The latter has never made into GDCM / ITK, or any other open source DICOM toolkit, since as quoted from the presentation: “Image Compression Refresher – JPEG 2000 and 3D, David Clunie”: the compression gain was modest (using lossless compression). We see now an opportunity that this compression can make it into GDCM / ITK since microscopy images would perfectly fit into the original design of the compression (ISO/IEC 15444-2:2003 Annex J). This would ease the dissemination of large dataset by reusing standard compression techniques, since this would greatly reduce the size of those file datasets. This will be particularly useful for microscopic images. At the time of writing no other open-source DICOM toolkit offer this compression algorithm.

=== Standard support for discrete 2 and 3 manifold storage in ITK ===
From its early design, ITK has always offered some n-dimensional n-manifold (polygonal meshes) support through the itk::Mesh class. However at the time of writing of this proposal, there is still no official way to read or write those meshes from and to a filesystem in ITK. Only an hybrid solution is available in Insight Applications. However it implies a dependency to the entire VTK library which is an overkill most of the time.
Thanks to the work on itk::QuadEdgeMesh some progress have been made toward that goal. The Review directory surrently holds a very simple VTK PolyData reader and writer. However, it only supports legacy vtk files using ASCII encoding. For its defense, this implementation was only made for regression testing and illustration of the filters usage.
We are proposing here to fill this gap in the ITK toolkit and implement DICOM's Supplement 132, part of the standard since 2008, which would add surfaces and volumes meshes (2 and 3 manifolds) storage capacity to GDCM /ITK. This would add support for surfaces and volume (2 and 3 manifolds in n dimensional space, see supplemental material annex).
We suggest 2 different options. The first option would allow for storage of itk::QuadEdgeMesh as a DICOM file. The second options would allow for storage of an itk::Mesh as a DICOM file. Of course reading the corresponding structures from a DICOM file would also be provided.
As an illustration, we make a clear distinction in what itk::QuadEdgeMesh handles and what itk::Mesh can handle. Both 2 and 3 manifold objects are handled in the DICOM standard.
We do anticipate a large portion of this task to be validation testing. Since there are no other serialization mechanism available in ITK, we will need to setup an hybrid system with VTK to perform validation on the dataset written (a 3D VTK mesh will be used as input for the tests). For this we would be re-using code from InsightApplications/Auxiliary/vtk/vtk2itk.cxx.

<div style="margin: 20px;">
<div style="width: 27%; float: left; padding-right: 3%;">

<h3>Objective</h3>
The objectives of the project week is to share with the community and make a list of persons interested and of corresponding efforts before we start implementing. Typically at the end of the week we would like to have identified existing parts, ongoing effort and have a roadmap available possibly with other groups joining in depending on needs, manpower and expertise.

</div>
<div style="width: 27%; float: left; padding-right: 3%;">

<h3>Approach, Plan</h3>
'''1.''' Item #1: Compare existing technologies: HDF5, DICOM, JPEG2000, TIFF (XMP)

'''2.''' Item #2: Identify technologies in ITK: openjpeg v1 which does not support tiles (required for streaming)

'''3.''' Item #3: Identify group which would need this technology: maybe CTK ?

</div>
<div style="width: 40%; float: left;">

<h3>Progress</h3>

'''*''' Worked with Kishore for ITK/JPEG 2000 reader. Code review / Made it compile

'''*''' Need to synchronize effort with GDCM 2.x and OpenJPEG v2 update. Prepare patch for GDCM 2.x to use openjpeg v2.

'''*''' Worked with GoFigure2 team to identify the need:
** passing algorithm more than passing data.
** image data
** very large image 4D
** mesh based segmentation (2d / 3d mesh)
** annotations (label)

'''*''' XMP technogoly is based on XML, which imply ASCII serialization (poor performance, very verbose).

</div>
</div>

<div style="width: 97%; float: left;">

==Delivery Mechanism==

This work will be delivered to the NA-MIC Kit as a

* ITK Module
* Other: GDCM extension (gdcm is included in ITK)

==References==
*the official DICOM Standard Proposal [ftp://medical.nema.org/medical/dicom/supps/sup145_09.pdf here]

</div>

2010 Project Week DICOM supplement 145

2010-06-25T13:49:12Z

Mathieu: /* Standard support for discrete 2 and 3 manifold storage in ITK */

__NOTOC__
<gallery>
Image:PW-MIT2010.png|[[2010_Summer_Project_Week#Projects|Projects List]]
</gallery>

==Key Investigators==
* Mathieu Malaterre: CoSMo Software
* Alex. Gouaillard: CoSMo SOftware, A*STAR
* Luis Ibanez: Kitware Inc.

==Project==
DICOM Supplement 145 provide a way to go over the 32bits limits and allow storing of large images. We propose to implement this specification.
In addition, we would implement DICOM specification for JPEG 2000 Part 2 Multi-component Image Compression. This portion of the standard provides higher
compression ratio for storing multicomponent images.
Finally by implementing DICOM supplement 132, we would provides support for storing of surfaces and 3D volumes, as an addition to the 2D RTSTRUCT.

=== Standard support for Large multicomponent images in ITK ===
DICOM currently defines Image IODs by storing the rows and columns as unsigned short
integer. This means that an image can only be at most of size 2^16 * 2^16 pixels.
This is a limitation for Microscopy Images as , for example, typical Whole Slice Images an be 60,000 * 80,000 pixels. Since images are generally stored with 24-bit color
pixels, this means WSI can go up to 15Gb. Confocal Microscopy Images add one additional
dimension, and are today already capable of acquiring 24 channels. They are reported to need up
to petabytes.
For this reason DICOM Supplement 145 defines a way to store images into multiple
DICOM files providing a mean to work around this 32bits limitation of DICOM.
By implementing this Supplement (which is still in Ballot), we would provide to the
ITK community a proof of concept and allow people to start saving larges images using DICOM.
This would allow the re-using of technologies and prevent people from re-inventing the wheel
and start using a new file format to exchange medical image (second system effect).

=== Standard support for multicomponent images compression in ITK ===
Microscopy Images, on top of being larger sometimes by several orders of magnitudes from medical images, are also multi-component. Even though ITK handle multicomponent images per say, by defining the right pixel type, nothing is available today for the storage and compression of images that would have more than 3 channels (RGB). Since 2001, the DICOM standard allows JPEG 2000 compression. GDCM 2.x has supported a portion of the standard by providing an API to allow transfer syntax such as JPEG 2000 Image Compression (1.2.840.10008.1.2.4.90 and 1.2.840.10008.1.2.4.91). However the standard also includes JPEG 2000 Part 2 Multi-component Image Compression (1.2.840.10008.1.2.4.92 and 1.2.840.10008.1.2.4.93). The latter has never made into GDCM / ITK, or any other open source DICOM toolkit, since as quoted from the presentation: “Image Compression Refresher – JPEG 2000 and 3D, David Clunie”: the compression gain was modest (using lossless compression). We see now an opportunity that this compression can make it into GDCM / ITK since microscopy images would perfectly fit into the original design of the compression (ISO/IEC 15444-2:2003 Annex J). This would ease the dissemination of large dataset by reusing standard compression techniques, since this would greatly reduce the size of those file datasets. This will be particularly useful for microscopic images. At the time of writing no other open-source DICOM toolkit offer this compression algorithm.

=== Standard support for discrete 2 and 3 manifold storage in ITK ===
From its early design, ITK has always offered some n-dimensional n-manifold (polygonal meshes) support through the itk::Mesh class. However at the time of writing of this proposal, there is still no official way to read or write those meshes from and to a filesystem in ITK. Only an hybrid solution is available in Insight Applications. However it implies a dependency to the entire VTK library which is an overkill most of the time.
Thanks to the work on itk::QuadEdgeMesh some progress have been made toward that goal. The Review directory surrently holds a very simple VTK PolyData reader and writer. However, it only supports legacy vtk files using ASCII encoding. For its defense, this implementation was only made for regression testing and illustration of the filters usage.
We are proposing here to fill this gap in the ITK toolkit and implement DICOM's Supplement 132, part of the standard since 2008, which would add surfaces and volumes meshes (2 and 3 manifolds) storage capacity to GDCM /ITK. This would add support for surfaces and volume (2 and 3 manifolds in n dimensional space, see supplemental material annex).
We suggest 2 different options. The first option would allow for storage of itk::QuadEdgeMesh as a DICOM file. The second options would allow for storage of an itk::Mesh as a DICOM file. Of course reading the corresponding structures from a DICOM file would also be provided.
As an illustration, we make a clear distinction in what itk::QuadEdgeMesh handles and what itk::Mesh can handle. Both 2 and 3 manifold objects are handled in the DICOM standard.
We do anticipate a large portion of this task to be validation testing. Since there are no other serialization mechanism available in ITK, we will need to setup an hybrid system with VTK to perform validation on the dataset written (a 3D VTK mesh will be used as input for the tests). For this we would be re-using code from InsightApplications/Auxiliary/vtk/vtk2itk.cxx.

<div style="margin: 20px;">
<div style="width: 27%; float: left; padding-right: 3%;">

<h3>Objective</h3>
The objectives of the project week is to share with the community and make a list of persons interested and of corresponding efforts before we start implementing. Typically at the end of the week we would like to have identified existing parts, ongoing effort and have a roadmap available possibly with other groups joining in depending on needs, manpower and expertise.

</div>
<div style="width: 27%; float: left; padding-right: 3%;">

<h3>Approach, Plan</h3>
'''1.''' Item #1: Compare existing technologies: HDF5, DICOM, JPEG2000, TIFF

</div>
<div style="width: 40%; float: left;">

<h3>Progress</h3>

'''*''' Worked with Kishore for ITK/JPEG 2000 reader. Code review / Made it compile

'''*''' Need to synchronize effort with GDCM 2.x and OpenJPEG v2 update

'''*''' Worked with GoFigure2 team to identify the need:
** passing algorithm more than passing data.
** image data
** very large image 4D
** mesh based segmentation (2d / 3d mesh)
** annotations (label)

</div>
</div>

<div style="width: 97%; float: left;">

==Delivery Mechanism==

This work will be delivered to the NA-MIC Kit as a

* ITK Module
* Other: GDCM extension (gdcm is included in ITK)

==References==
*the official DICOM Standard Proposal [ftp://medical.nema.org/medical/dicom/supps/sup145_09.pdf here]

</div>

User:Mathieu

2010-04-13T11:44:21Z

Mathieu:

[mailto:mathieu.malaterre@gmail.com Mathieu Malaterre]

[http://www.mathieumalaterre.com Home Page]

Microscopy Image Analysis

2010-04-13T10:34:03Z

Mathieu: /* Participants */

= Open Workshop on Microscopy Image Analysis in ITK and VTK =
The goal of this workshop is to foster the growth of a community of scientists interested in microscopy image analysis for biology using ITK and VTK

== Background ==
Optical microscopy is by far the most common form of imaging in biomedical research due to its high spatial resolution (subcellular), high specificity (molecular in the case of fluorescence), and suitability for use in living specimens. A Google Scholar search for "fluorescence microscopy", only one of several types of optical microscopy, returns 1.7 million articles compared with < 1 million for "MRI". Traditionally, the vast majority of these users of microscopy have performed qualitative analysis on a small number of images, but this is quickly changing. There is increasingly a need to perform quantitative analysis on microscopy images and to perform this analysis on large image sets (>100,000 images). In addition to higher throughput, recent advances in microscopy have made higher dimensional imaging commonplace. Researchers now routinely capture microscopy images over the dimensions of space (x,y,z), time (t), and multiple channels of color (lambda). Due to the large datasets, high dimensions, and complexity of analysis, current approaches to microscopy image analysis relying on Java, Matlab, and “home brew” applications are reaching their limits. We believe that a community based effort centered on developing microscopy-specific algorithms and applications built on the C++ class libraries of VTK and ITK represents the best path forward.

== Focus ==
The focus of this workshop will be on segmentation and tracking of cells in optical microscopy images. Segmentation and tracking of cells represents a very common problem in microscopy image analysis. Although there is a common pipeline for many users (e.g. image preprocessing to remove noise, detection of seeds, detection of cells at single timepoints, tracking movements over time, data analysis) the algorithm parameters and algorithms themselves are often dependent on the specifics of the experimental setup. There is thus a strong need to develop a framework to allow users to choose algorithms and tune parameters to most importantly achieve robust segmentation and secondarily minimize computational cost.

==Format==
The format for this meeting will be as a “track” within the NAMIC Project Week 2010 meeting at MIT in Boston, MA on June 21-25. Participants in this workshop should all have specific coding projects relating to cell segmentation and tracking that they wish to complete within the week. Ideally these projects should be collaborative. At the beginning of the meeting on Monday, workshop participants will present a 1 slide summary of the goals of their project as part of the overall meeting. For the rest of the week, workshop participants will sit in a common area and code on their projects. We will also have a microscopy breakout session on Wednesday. These project weeks tend to be quite productive because of the concentration of available expertise at the meeting. During the week we will also break from the coding to have a more formal discussion of our current individual efforts, the needs of the microscopy community, the technical issues of combining and exchanging code, and how we should move forward.

== Schedule ==
* Monday afternoon- 1 slide lightning talk of project planned for the week
* Wednesday afternoon
** Current efforts (15 minute talks per lab)
** Roundtable discussion of standards/interfaces
*** Image file types
*** Input-output interface for segmentation and tracking filters
*** Format for outputted data (e.g. automatic annotations of cell size, intensity, cell type)
*** Greatest common denominator of code: ITK classes, compound filters in ITK, plugins?
*** Common human tasks
**** Manual segmentation and editing of results
**** Visualization of results
** Future directions
* Friday- 1 slide summary of results for the week
* The rest of the time will be spent coding on projects

== Projects ==
The meat of this workshop is project work. This work should be collaborative to fully take advantage of everyone being together at the conference, to learn other people's approaches, and to flesh out the important needs of microscopy image analysis. If you need help formulating a project please contact Arnaud Gelas (arnaud_gelas@hms.harvard.edu) who can help as a matchmaker. Please list your projects below
* DICOM supplement [ftp://medical.nema.org/medical/dicom/supps/sup145_09.pdf 145]: Microscopy Image in the Dicom Standard ( Malaterre, Gouaillard )
* Microscopy pre-processing extension of ITK: convolution, deconvolution, wavelets and more ( Laehman, Gouaillard )
* Flow Cytometry ( Gouaillard )
* --

== Participants ==
Please add your name to the list if you are interested in participating in this workshop
# Raghu Machiraju, Ohio State University
# Kannappan Palaniappan, University of Missouri
# Badri Roysam, Rensselaer Polytechnic Institute
# Arnaud Gelas, Harvard Medical School
# Kishore Mosaliganti, Harvard Medical School
# Nicolas Rannou, Harvard Medical School
# Antonin Perrot-Audet, Harvard Medical School
# Lydie Souhait, Harvard Medical School
# Sean Megason, Harvard Medical School
# Luis Ibanez, Kitware
# Gaetan Lehmann, INRA, Platform of Microscopy and Imaging of Micro-Organism, Animals and Ailments
# Mathieu Malaterre, CoSMo
# Alex. Gouaillard. A*STAR / CoSMo

NAMIC Wiki:DTI:DICOM for DWI and DTI

2008-08-05T09:57:55Z

Mathieu: /* Private vendor: Siemens */

This page should serve as a place where information about DICOM and DWI/DTI data can be maintained. With time, this information could be used as part of automated solutions for learning all the necessary DWI-related information from a DICOM series. A collection of tools for DICOM is [[DICOM|here]].

As long DICOM support for DWI information is vendor-specific and/or non-conformant with the info here, the [[NAMIC_Wiki:DTI:Nrrd_format|Nrrd format ]] provides a means of recording the DWI-specific information once it is known.

== DICOM for DWI ==

The recommended tags to use in DICOM are as follows:

0018 9075 CS 1 Diffusion Directionality
0018 9076 SQ 1 Diffusion Gradient Direction Sequence
0018 9087 FD 1 Diffusion b-value
0018 9089 FD 3 Diffusion Gradient Orientation
0018 9117 SQ 1 MR Diffusion Sequence
0018 9147 CS 1 Diffusion Anisotropy Type

These are defined in [ftp://medical.nema.org/medical/dicom/final/sup49_ft.pdf Supplement 49]. In particular see section C.8.12.5.9 "MR Diffusion Macro" on pages 94 and 95.

The tags are also referenced in http://medical.nema.org/dicom/2004/04_06PU.PDF (see pages 28-29) as well as in some [http://medical.nema.org/Dicom/minutes/WG-07/WG-07_2005/Minutes-2005-10-20-21-Denver.doc Working Group Minutes] (see pages 155-156).

Two points of interest relative to the NRRD format:

* The definition of "Diffusion Gradient Orientation" implies that the measurement frame is exactly the identity transform.
* There appears to be no means of recording the full B-matrix when it is known. This is not an issue for any NAMIC datasets, but can arise in small-bore imaging.

== Private vendor: GE ==

For GE scanners, Signa Excite 12.0 and later, the following tags are reserved for diffusion weighted images:

* (0019,10e0) : # DTI diffusion directions (release 10.0 & above)
* (0019,10df) : # DTI diffusion directions (release 9.0 & below)
* (0019,10d9) : Concatenated SAT {# DTI Diffusion Dir., release 9.0 & below}
* (0021,105A) : diffusion direction
* (0043,1039) : Slop_int_6... slop_int_9: (in the GEMS_PARM_01 block)
** 6: b_value
** 7: private imaging options 2
** 8: ihtagging
** 9: ihtagspc

This information can be found in http://www.gehealthcare.com/usen/interoperability/dicom/docs/5162373r1.pdf

Unfortunately the [[DataRepository|Dartmouth DWI data ]] (from a GE Signa scanner) does not conform to this (nor do they use the nominally standard 0x0018 tags), as can be seen by running:

dcdump S4.100 | & grep \(0x0019,0x10

which includes:

(0x0019,0x10d9) DS Concatenated SAT VR=<DS> VL=<0x0008> <0.000000>
(0x0019,0x10df) DS User Data VR=<DS> VL=<0x0008> <0.000000>
(0x0019,0x10e0) DS User Data VR=<DS> VL=<0x0008> <0.000000>

so all of the tags which are supposed to store # gradient directions store the value 0! In addition, there is:

(0x0021,0x105a) SL Integer Slop VR=<SL> VL=<0x0004> [0x00000000]

so the supposed representation of diffusion-direction is also empty. The Dartmouth data has the following tags describing the scanner and software version:

(0008,1090) LO [GENESIS_SIGNA]
(0018,1020) LO [09]

In GE DWI images (software version 12.0)

(0008,1090) LO [SIGNA EXCITE]
(0018,1020) LO [12\LX\MR Software release:12.0_M4_0520.a]

diffusion directions are stored under the following tags:

(0019,10bb) DS [0.430617]
(0019,10bc) DS [-0.804161]
(0019,10bd) DS [-0.420008]

== Private vendor: Siemens ==

A Siemens DICOM Conformance Statement is available at

http://www.medical.siemens.com/siemens/en_INT/rg_marcom_FBAs/files/brochures/DICOM/mr/dcs_trio.pdf

No diffusion related tags specified.

David Tuch has stated (in email from December 21, 2005):

The diffusion gradient information and coordinate frame are not provided
in the DICOM hdr for the MGH diffusion sequences.

'''Tag 0029,1010''' may include all necessary information

If you have installed spm (and Matlab), the following spm-File extracts the gradient info:

P= spm_get(Inf,'*','Selct some files')
hdr=spm_dicom_headers(P)
hdr{1}.CSAImageHeaderInfo(22).item(1).val
hdr{1}.CSAImageHeaderInfo(22).item(2).val
hdr{1}.CSAImageHeaderInfo(22).item(3).val

look for "spm_dicom_headers.m" (google or on your hard disk), this spm File shows you how to decode the tag data.

It is easy to write a C or C++ program that does the same, if you have the spm_dicom_headers.m

Credits: Jan Klein <klein AT mevis DOT de>

Another solution is simply to download GDCM 2.x application (gdcmdump) and type:

$ gdcmdump --csa input.dcm

Output should look like:

<pre>
(0029,0010)siemens csa header
Image shadow data (0029,xx10)

0 - 'EchoLinePosition' VM 1, VR IS, SyngoDT 6, NoOfItems 6, Data '192 '
1 - 'EchoColumnPosition' VM 1, VR IS, SyngoDT 6, NoOfItems 6, Data '128 '
2 - 'EchoPartitionPosition' VM 1, VR IS, SyngoDT 6, NoOfItems 6, Data '16 '
3 - 'UsedChannelMask' VM 1, VR UL, SyngoDT 9, NoOfItems 6, Data '255 '
4 - 'Actual3DImaPartNumber' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
5 - 'ICE_Dims' VM 1, VR LO, SyngoDT 19, NoOfItems 6, Data 'X_1_1_1_1_1_1_1_1_1_1_1_136'
6 - 'B_value' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
7 - 'Filter1' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
8 - 'Filter2' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
9 - 'ProtocolSliceNumber' VM 1, VR IS, SyngoDT 6, NoOfItems 6, Data '0 '
10 - 'RealDwellTime' VM 1, VR IS, SyngoDT 6, NoOfItems 6, Data '7500 '
11 - 'PixelFile' VM 1, VR UN, SyngoDT 0, NoOfItems 0, Data
12 - 'PixelFileName' VM 1, VR UN, SyngoDT 0, NoOfItems 0, Data
13 - 'SliceMeasurementDuration' VM 1, VR DS, SyngoDT 3, NoOfItems 6, Data '73375.00000000'
14 - 'SequenceMask' VM 1, VR UL, SyngoDT 9, NoOfItems 6, Data '0 '
15 - 'AcquisitionMatrixText' VM 1, VR SH, SyngoDT 22, NoOfItems 6, Data '256*256'
16 - 'MeasuredFourierLines' VM 1, VR IS, SyngoDT 6, NoOfItems 6, Data '0 '
17 - 'FlowEncodingDirection' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
18 - 'FlowVenc' VM 1, VR FD, SyngoDT 4, NoOfItems 0, Data
19 - 'PhaseEncodingDirectionPositive' VM 1, VR IS, SyngoDT 6, NoOfItems 6, Data '1 '
20 - 'NumberOfImagesInMosaic' VM 1, VR US, SyngoDT 10, NoOfItems 0, Data
21 - 'DiffusionGradientDirection' VM 3, VR FD, SyngoDT 4, NoOfItems 0, Data
22 - 'ImageGroup' VM 1, VR US, SyngoDT 10, NoOfItems 0, Data
23 - 'SliceNormalVector' VM 3, VR FD, SyngoDT 4, NoOfItems 0, Data
24 - 'DiffusionDirectionality' VM 1, VR CS, SyngoDT 16, NoOfItems 0, Data
25 - 'TimeAfterStart' VM 1, VR DS, SyngoDT 3, NoOfItems 6, Data '0.00000000'
26 - 'FlipAngle' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
27 - 'SequenceName' VM 1, VR SH, SyngoDT 22, NoOfItems 0, Data
28 - 'RepetitionTime' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
29 - 'EchoTime' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
30 - 'NumberOfAverages' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
31 - 'VoxelThickness' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
32 - 'VoxelPhaseFOV' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
33 - 'VoxelReadoutFOV' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
34 - 'VoxelPositionSag' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
35 - 'VoxelPositionCor' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
36 - 'VoxelPositionTra' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
37 - 'VoxelNormalSag' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
38 - 'VoxelNormalCor' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
39 - 'VoxelNormalTra' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
40 - 'VoxelInPlaneRot' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
41 - 'ImagePositionPatient' VM 3, VR DS, SyngoDT 3, NoOfItems 0, Data
42 - 'ImageOrientationPatient' VM 6, VR DS, SyngoDT 3, NoOfItems 0, Data
43 - 'PixelSpacing' VM 2, VR DS, SyngoDT 3, NoOfItems 0, Data
44 - 'SliceLocation' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
45 - 'SliceThickness' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
46 - 'SpectrumTextRegionLabel' VM 1, VR SH, SyngoDT 22, NoOfItems 0, Data
47 - 'Comp_Algorithm' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
48 - 'Comp_Blended' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
49 - 'Comp_ManualAdjusted' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
50 - 'Comp_AutoParam' VM 1, VR LT, SyngoDT 20, NoOfItems 0, Data
51 - 'Comp_AdjustedParam' VM 1, VR LT, SyngoDT 20, NoOfItems 0, Data
52 - 'Comp_JobID' VM 1, VR LT, SyngoDT 20, NoOfItems 0, Data
53 - 'FMRIStimulInfo' VM 1, VR IS, SyngoDT 6, NoOfItems 0, Data
54 - 'FlowEncodingDirectionString' VM 1, VR SH, SyngoDT 22, NoOfItems 0, Data
55 - 'RepetitionTimeEffective' VM 1, VR DS, SyngoDT 3, NoOfItems 0, Data
56 - 'CsiImagePositionPatient' VM 3, VR DS, SyngoDT 3, NoOfItems 0, Data
57 - 'CsiImageOrientationPatient' VM 6, VR DS, SyngoDT 3, NoOfItems 0, Data
...
</pre>

Ref:
* http://gdcm.sourceforge.net/wiki/index.php/GDCM_Release_2.0

=== Update ===

<br /> As far as the latest MR scanner software (2006) version is concerned, a solution for the access of the following Diffusion attributes was provided:

0019;000A;SIEMENS MR HEADER ;NumberOfImagesInMosaic ;1;US;1
0019;000B;SIEMENS MR HEADER ;SliceMeasurementDuration ;1;DS;1
0019;000C;SIEMENS MR HEADER ;B_value ;1;IS;1
0019;000D;SIEMENS MR HEADER ;DiffusionDirectionality ;1;CS;1
0019;000E;SIEMENS MR HEADER ;DiffusionGradientDirection ;1;FD;3
0019;000F;SIEMENS MR HEADER ;GradientMode ;1;SH;1
0019;0027;SIEMENS MR HEADER ;B_matrix ;1;FD;6
0019;0028;SIEMENS MR HEADER ;BandwidthPerPixelPhaseEncode ;1;FD;1

That does not solve your problem with the older datasets and unfortunately there is no easy way to access diffusion information there as it is really only stored in the Siemens shadow part.

Credits: Stefan Huwer

=== User Note ===

Don't use the gradient-directions from the DICOM header from VB13 systems, it commonly contains errors; read the b-matrix instead and use that to compute the gradient-directions. In fact, this is also what Siemens does but they compute the gradient-vectors in an error-prone way. They do (in Matlab syntax):

% BMtx = [bxx bxy bxz byy byz bzz]
GradVec = BMtx([1:3])/sqrt(BVal*BMtx([1]));

This gives errors for bxx values of zero and close to one (bxx is an integer); NB this *does* happen! So instead read the b-matrix and do:

BSign = sign(sign(BMtx([1:3])) + 0.01); % Adding 0.01 avoids getting zeros here
GradVec = BSign .* sqrt(BMtx([1 4 6])/BVal);

In this way, the vectors may point exactly in the opposite direction (sign flip), but this is usually of no importance.

Furthermore, the stored values may differ from the official values due to the fact that
# the directions are calculated from the b-matrix and not directly written to the header. Rounding errors, as well as sign flips may occur in this case.
# the b-matrix takes also the diffusion effect of imaging and spoiling gradients into account. This leads to deviations from the originally specified orientations.
# the vectors are expressed in the patient coordinate system (Sag/Cor/Tra), not in Slice/Read/Phase, following the DICOM convention.

Credits: Marcel Zwiers

=== Reference ===

* http://www.mmrrcc.upenn.edu/CAMRIS/cfn/

in particular:

* http://www.mmrrcc.upenn.edu/CAMRIS/cfn/dicomhdr.html

== Private vendor: Philips ==

Philips uses the following tags for diffusion weighted images

* (2001,1003) : B_value;
* (2001,1004) : Diffusion direction.

Complete DICOM conformance statements for

* Intera
* Achieva
* Panorama
* Gyroscan
* Infinion / Eclipse

are available here http://www.medical.philips.com/main/company/connectivity/mri/

=== DTI Table Gradient ===

OVERVIEW:

This applet computes the gradient table
for DTI data acquired on Philips MRI
scanners with low, medium, and high
directional resolution.

The imaging parameters and DTI options
listed can affect the gradient table.
e.g.directions from a gradient overplus
= yes table need to be adjusted for the
slice angulation (i.e. oblique slices)
specific to each DTI study

The output is appropriate for DTIstudio.
I hope this applet is useful, but please
use it at your own risk. Matlab code with
more functionality is available on my
webpage

* http://godzilla.kennedykrieger.org/%7Ejfarrell/OTHERphilips/GUI.html

== DICOM for estimated diffusion tensors ==

There is no specification right now in DICOM to support Tensor. Only a supplement:

[ftp://medical.nema.org/medical/dicom/supps/sup63_pc.pdf Supp 63 Parts 3,4,5,6,16,17 Multi-dimensional Interchange Object ]

The discussion would then be (D. Clunie quote):

Indeed, even if one were to try to standardize in DICOM the encoding
of the entire diffusion tensor, there would no doubt be considerable
debate as to whether to do that as 6 (or 9) planes of an "image", since
there is such a matrix at each spatial location ("pixel"), or as
a special case of the proposed Sup 63 object; the former would keep
image-oriented tools and software happier, the latter would require
implementing a new mechanism and navigating through a more general
structure.

== Discussion on DICOM newsgroup ==

http://groups.google.com/group/comp.protocols.dicom/browse_frm/thread/3d292d9c506b1cbf For cross reference:

Hi Mathieu

Thanks for the very interesting links.

The proposed standard way to address this problem is with
the Enhanced MR IOD, which explicitly addresses the
attributes for encoding diffusion directionality and B-Value.

There will likely be no extensions of the existing MR IOD to
address this concern, since by policy, we obviously want
folks to use the new IOD.

It would not surprise me if in the interim, vendors started
to send some of the new Sup 49 attributes in old IOD
instances, but there will almost certainly be no official move
to standardize this, and we would certainly not consider
adding a non-Sup 49 based mechanism.

If the Sup 49 mechanisms are not sufficient (e.g. for
tensors), then we need to discuss what the gaps are
and how to fill them.

We would not, by the way, ever "encapsulate" the NRRD
header, but it would nice if there was a clear mapping between
the DICOM Sup 49 attributes and the relevant NRRD
attributes, though these are probably obvious.

David

Mathieu Malaterre wrote:
> Hello again,
>
> I am currently involved in a group which is working extensively with
> DWI data (diffusion-weighted image). Their acquisition data is coming
> in the form of DICOM files. Unfortunately they are currently facing two
> problems:
> 1. Each vendors stores the gradient directions differently (if at all!)
> 2. Even if you have the directions, you don't have the measurement
> frame(*). As far as I understand the DICOM specification, there is
> currently no way to store this type of information.
>
> For issue #1 I am currently gathering information about the major
> vendors so that I can add extraction code into gdcm. This would provide
> a function to extract the gradient directions and make invisible to
> user the different way vendors use to store this information. For more
> information see the Wiki at:
> http://www.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:DICOM_for_DWI_and_DTI
>
> For issue #2, -again correct me if I am wrong- but I could not find
> anything that could represent this measurement frame. Therefore the
> solution we are using is to use an intermediate file format called
> NRRD, see for instance:
> http://wiki.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:Nrrd_format
> Ideally this information should be accessible from a particular
> DICOM tag. Can we request an extension of the DICOM standard to allow
> us to store this information directly in the DICOM file, which would
> greatly simplify the process (avoiding the intermediate NRRD file
> format step).
>
> Regards,
> Mathieu
> (*)
> "measurement frame": relationship between the coordinate frame in which
> the gradient coefficients are expressed, and the physical coordinate
> frame in which image orientation is defined

NAMIC Wiki:DTI:DICOM for DWI and DTI

2007-09-06T08:49:03Z

Mathieu: /* Private vendor: Philips */

This page should serve as a place where information about DICOM and DWI/DTI data can be maintained. With time, this information could be used as part of automated solutions for learning all the necessary DWI-related information from a DICOM series. A collection of tools for DICOM is [[DICOM|here]].

As long DICOM support for DWI information is vendor-specific and/or non-conformant with the info here, the [[NAMIC_Wiki:DTI:Nrrd_format|Nrrd format ]] provides a means of recording the DWI-specific information once it is known.

== DICOM for DWI ==

The recommended tags to use in DICOM are as follows:

0018 9075 CS 1 Diffusion Directionality
0018 9076 SQ 1 Diffusion Gradient Direction Sequence
0018 9087 FD 1 Diffusion b-value
0018 9089 FD 3 Diffusion Gradient Orientation
0018 9117 SQ 1 MR Diffusion Sequence
0018 9147 CS 1 Diffusion Anisotropy Type

These are defined in [ftp://medical.nema.org/medical/dicom/final/sup49_ft.pdf Supplement 49]. In particular see section C.8.12.5.9 "MR Diffusion Macro" on pages 94 and 95.

The tags are also referenced in http://medical.nema.org/dicom/2004/04_06PU.PDF (see pages 28-29) as well as in some [http://medical.nema.org/Dicom/minutes/WG-07/WG-07_2005/Minutes-2005-10-20-21-Denver.doc Working Group Minutes] (see pages 155-156).

Two points of interest relative to the NRRD format:

* The definition of "Diffusion Gradient Orientation" implies that the measurement frame is exactly the identity transform.
* There appears to be no means of recording the full B-matrix when it is known. This is not an issue for any NAMIC datasets, but can arise in small-bore imaging.

=== Private vendor: GE ===

For GE scanners, Signa Excite 12.0 and later, the following tags are reserved for diffusion weighted images:

* (0019,10e0) : # DTI diffusion directions (release 10.0 & above)
* (0019,10df) : # DTI diffusion directions (release 9.0 & below)
* (0019,10d9) : Concatenated SAT {# DTI Diffusion Dir., release 9.0 & below}
* (0021,105A) : diffusion direction
* (0043,1039) : Slop_int_6... slop_int_9: (in the GEMS_PARM_01 block)
** 6: b_value
** 7: private imaging options 2
** 8: ihtagging
** 9: ihtagspc

This information can be found in http://www.gehealthcare.com/usen/interoperability/dicom/docs/5162373r1.pdf

Unfortunately the [[DataRepository|Dartmouth DWI data ]] (from a GE Signa scanner) does not conform to this (nor do they use the nominally standard 0x0018 tags), as can be seen by running:

dcdump S4.100 | & grep \(0x0019,0x10

which includes:

(0x0019,0x10d9) DS Concatenated SAT VR=<DS> VL=<0x0008> <0.000000>
(0x0019,0x10df) DS User Data VR=<DS> VL=<0x0008> <0.000000>
(0x0019,0x10e0) DS User Data VR=<DS> VL=<0x0008> <0.000000>

so all of the tags which are supposed to store # gradient directions store the value 0! In addition, there is:

(0x0021,0x105a) SL Integer Slop VR=<SL> VL=<0x0004> [0x00000000]

so the supposed representation of diffusion-direction is also empty. The Dartmouth data has the following tags describing the scanner and software version:

(0008,1090) LO [GENESIS_SIGNA]
(0018,1020) LO [09]

In GE DWI images (software version 12.0)

(0008,1090) LO [SIGNA EXCITE]
(0018,1020) LO [12\LX\MR Software release:12.0_M4_0520.a]

diffusion directions are stored under the following tags:

(0019,10bb) DS [0.430617]
(0019,10bc) DS [-0.804161]
(0019,10bd) DS [-0.420008]

=== Private vendor: Siemens ===

A Siemens DICOM Conformance Statement is available at

http://www.medical.siemens.com/siemens/en_INT/rg_marcom_FBAs/files/brochures/DICOM/mr/dcs_trio.pdf

No diffusion related tags specified.

David Tuch has stated (in email from December 21, 2005):

The diffusion gradient information and coordinate frame are not provided
in the DICOM hdr for the MGH diffusion sequences.

'''Tag 0029,1010''' may include all necessary information

If you have installed spm (and Matlab), the following spm-File extracts the gradient info:

P= spm_get(Inf,'*','Selct some files')
hdr=spm_dicom_headers(P)
hdr{1}.CSAImageHeaderInfo(22).item(1).val
hdr{1}.CSAImageHeaderInfo(22).item(2).val
hdr{1}.CSAImageHeaderInfo(22).item(3).val

look for "spm_dicom_headers.m" (google or on your hard disk), this spm File shows you how to decode the tag data.

It is easy to write a C or C++ program that does the same, if you have the spm_dicom_headers.m

Credits: Jan Klein <klein AT mevis DOT de>

==== Update ====

<br /> As far as the latest MR scanner software (2006) version is concerned, a solution for the access of the following Diffusion attributes was provided:

0019;000A;SIEMENS MR HEADER ;NumberOfImagesInMosaic ;1;US;1
0019;000B;SIEMENS MR HEADER ;SliceMeasurementDuration ;1;DS;1
0019;000C;SIEMENS MR HEADER ;B_value ;1;IS;1
0019;000D;SIEMENS MR HEADER ;DiffusionDirectionality ;1;CS;1
0019;000E;SIEMENS MR HEADER ;DiffusionGradientDirection ;1;FD;3
0019;000F;SIEMENS MR HEADER ;GradientMode ;1;SH;1
0019;0027;SIEMENS MR HEADER ;B_matrix ;1;FD;6
0019;0028;SIEMENS MR HEADER ;BandwidthPerPixelPhaseEncode ;1;FD;1

That does not solve your problem with the older datasets and unfortunately there is no easy way to access diffusion information there as it is really only stored in the Siemens shadow part.

Credits: Stefan Huwer

==== User Note ====

Don't use the gradient-directions from the DICOM header from VB13 systems, it commonly contains errors; read the b-matrix instead and use that to compute the gradient-directions. In fact, this is also what Siemens does but they compute the gradient-vectors in an error-prone way. They do (in Matlab syntax):

% BMtx = [bxx bxy bxz byy byz bzz]
GradVec = BMtx([1:3])/sqrt(BVal*BMtx([1]));

This gives errors for bxx values of zero and close to one (bxx is an integer); NB this *does* happen! So instead read the b-matrix and do:

BSign = sign(sign(BMtx([1:3])) + 0.01); % Adding 0.01 avoids getting zeros here
GradVec = BSign .* sqrt(BMtx([1 4 6])/BVal);

In this way, the vectors may point exactly in the opposite direction (sign flip), but this is usually of no importance.

Furthermore, the stored values may differ from the official values due to the fact that
# the directions are calculated from the b-matrix and not directly written to the header. Rounding errors, as well as sign flips may occur in this case.
# the b-matrix takes also the diffusion effect of imaging and spoiling gradients into account. This leads to deviations from the originally specified orientations.
# the vectors are expressed in the patient coordinate system (Sag/Cor/Tra), not in Slice/Read/Phase, following the DICOM convention.

Credits: Marcel Zwiers

==== Reference ====

* http://www.mmrrcc.upenn.edu/CAMRIS/cfn/

in particular:

* http://www.mmrrcc.upenn.edu/CAMRIS/cfn/dicomhdr.html

=== Private vendor: Philips ===

Philips uses the following tags for diffusion weighted images

* (2001,1003) : B_value;
* (2001,1004) : Diffusion direction.

Complete DICOM conformance statements for

* Intera
* Achieva
* Panorama
* Gyroscan
* Infinion / Eclipse

are available here http://www.medical.philips.com/main/company/connectivity/mri/

==== DTI Table Gradient ====

OVERVIEW:

This applet computes the gradient table
for DTI data acquired on Philips MRI
scanners with low, medium, and high
directional resolution.

The imaging parameters and DTI options
listed can affect the gradient table.
e.g.directions from a gradient overplus
= yes table need to be adjusted for the
slice angulation (i.e. oblique slices)
specific to each DTI study

The output is appropriate for DTIstudio.
I hope this applet is useful, but please
use it at your own risk. Matlab code with
more functionality is available on my
webpage

* http://godzilla.kennedykrieger.org/%7Ejfarrell/OTHERphilips/GUI.html

== DICOM for estimated diffusion tensors ==

There is no specification right now in DICOM to support Tensor. Only a supplement:

[ftp://medical.nema.org/medical/dicom/supps/sup63_pc.pdf Supp 63 Parts 3,4,5,6,16,17 Multi-dimensional Interchange Object ]

The discussion would then be (D. Clunie quote):

Indeed, even if one were to try to standardize in DICOM the encoding
of the entire diffusion tensor, there would no doubt be considerable
debate as to whether to do that as 6 (or 9) planes of an "image", since
there is such a matrix at each spatial location ("pixel"), or as
a special case of the proposed Sup 63 object; the former would keep
image-oriented tools and software happier, the latter would require
implementing a new mechanism and navigating through a more general
structure.

== Discussion on DICOM newsgroup ==

http://groups.google.com/group/comp.protocols.dicom/browse_frm/thread/3d292d9c506b1cbf For cross reference:

Hi Mathieu

Thanks for the very interesting links.

The proposed standard way to address this problem is with
the Enhanced MR IOD, which explicitly addresses the
attributes for encoding diffusion directionality and B-Value.

There will likely be no extensions of the existing MR IOD to
address this concern, since by policy, we obviously want
folks to use the new IOD.

It would not surprise me if in the interim, vendors started
to send some of the new Sup 49 attributes in old IOD
instances, but there will almost certainly be no official move
to standardize this, and we would certainly not consider
adding a non-Sup 49 based mechanism.

If the Sup 49 mechanisms are not sufficient (e.g. for
tensors), then we need to discuss what the gaps are
and how to fill them.

We would not, by the way, ever "encapsulate" the NRRD
header, but it would nice if there was a clear mapping between
the DICOM Sup 49 attributes and the relevant NRRD
attributes, though these are probably obvious.

David

Mathieu Malaterre wrote:
> Hello again,
>
> I am currently involved in a group which is working extensively with
> DWI data (diffusion-weighted image). Their acquisition data is coming
> in the form of DICOM files. Unfortunately they are currently facing two
> problems:
> 1. Each vendors stores the gradient directions differently (if at all!)
> 2. Even if you have the directions, you don't have the measurement
> frame(*). As far as I understand the DICOM specification, there is
> currently no way to store this type of information.
>
> For issue #1 I am currently gathering information about the major
> vendors so that I can add extraction code into gdcm. This would provide
> a function to extract the gradient directions and make invisible to
> user the different way vendors use to store this information. For more
> information see the Wiki at:
> http://www.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:DICOM_for_DWI_and_DTI
>
> For issue #2, -again correct me if I am wrong- but I could not find
> anything that could represent this measurement frame. Therefore the
> solution we are using is to use an intermediate file format called
> NRRD, see for instance:
> http://wiki.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:Nrrd_format
> Ideally this information should be accessible from a particular
> DICOM tag. Can we request an extension of the DICOM standard to allow
> us to store this information directly in the DICOM file, which would
> greatly simplify the process (avoiding the intermediate NRRD file
> format step).
>
> Regards,
> Mathieu
> (*)
> "measurement frame": relationship between the coordinate frame in which
> the gradient coefficients are expressed, and the physical coordinate
> frame in which image orientation is defined

NAMIC Wiki:DTI:DICOM for DWI and DTI

2007-06-06T08:36:32Z

Mathieu: /* Update */

Slicer3:Data Model

2007-05-24T13:02:45Z

Mathieu: /* MRML API Documentation */

= Slicer3 MRML Overview =

*MRML Library provides API for managing medical image data types (Volumes, Models, Transforms, Fiducials, Cameras, etc) and their visualization.
*Each data type is represented by a special MRML node.
*MRML Scene is a collection of MRML nodes.
*Slicer MRML data model is implemented independent of the visualization and algorithmic components of the system.
*Other Slicer components (Logic and GUI) observe changes in MRML scene and individual nodes and process change MRML events.

For more details on MRML architecture see [http://www.na-mic.org/Wiki/images/e/e3/Slicer_3-alpha-2006-04-03.ppt Architecture Slides].

= MRML Scene =

*MRML Scene manages MRML nodes : add, delete, find, find by type, etc.
*MRML Scene provides persistence of MRML nodes (reading/writing to/from XML file).
*MRML Scene provides Undo/Redo mechanism that restores a previous state of the scene and individual nodes.

= MRML Nodes =

*The MRML nodes are designed to store the state of the Slicer application, both raw data and visualization parameters.

There following is a set of core MRLN nodes that store the state of core Slicer modules:

* vtkMRMLCameraNode
* vtkMRMLClipModelsNode
* vtkMRMLSliceCompositeNode
* vtkMRMLSliceNode
* vtkMRMLColorNode
* vtkMRMLTransformNode
* vtkMRMLLinearTransformNode
* vtkMRMLTransformableNode
* vtkMRMLFiducialListNode
* vtkMRMLModelNode
* vtkMRMLModelDisplayNode
* vtkMRMLStorageNode
* vtkMRMLModelStorageNode
* vtkMRMLVolumeNode
* vtkMRMLScalarVolumeNode
* vtkMRMLVectorVolumeNode
* vtkMRMLTensorVolumeNode
* vtkMRMLDiffusionTensorVolumeNode
* vtkMRMLDiffusionWeightedVolumeNode
* vtkMRMLVolumeDisplayNode
* vtkMRMLVectorVolumeDisplayNode
* vtkMRMLDiffusionTensorVolumeDisplayNode
* vtkMRMLDiffusionWeightedVolumeDisplayNode
* vtkMRMLVolumeHeaderlessStorageNode
* vtkMRMLVolumeArchetypeStorageNode

<br />
*MRML nodes are organized into C++ class hierarchies, all derived from vtkMRMLNode class.
*For example vtkMRMLTransformableNode is the parent class of Volume, Model, Fiducial, and Transformation nodes; vtkVolumeNode is a parent of vtkMRMLScalarVolumeNode and vtkMRMLVectorVolumeNode
*All MRML nodes have to implement certain standard API: ReadAttributes, WriteAttributes, Copy, etc.
{|
|[[Image: Slicer3_MRML_Node_Hier.jpg|thumb|400px]]
|}

= References to MRML Nodes =

*Some MRML nodes have references to other nodes.
*Transformable Node has a reference to a Transformation node. Transformation node has a reference to its parent Transformation node.
*References are stored by node ID.
*Use vtkSetReferenceStringMacro to set reference ID (it registers reference with the scene).
*Access methods should check if the referenced node is still in the MRML scene using its ID.
{|
|[[Image: Slicer3_MRML_Trans_Ref.jpg|thumb|400px]]
|}

= MRML Events and Observers =

*Changes in MRML scene and individual nodes propagate to other observing nodes, GUI and Logic objects via vtk events and command-observer mechanism.
*Use vtk AddObserver() and InvokeEvent() methods. vtk SetMacro generates ModifiedEvent.
*The command-observer mechanism for MRML is implemented using helper vtkObserverManager, class, MRML Observer macros, and ProcessMRMLEvents method.
*Observers should store a registered pointer to a MRML node to prevent callbacks on a deleted object.
{|
|[[Image: Slicer3_MRML_Observ.jpg|thumb|400px]]
|}

*MRML observer macros are defined in Libs/MRML/vtkMRMLNode.h
*VtkSetMRMLObjectMacro - registers MRML node with another vtk object (another MRML node, Logic or GUI). No observers added.
*VtkSetAndObserveMRMLObjectMacro - registers MRML node and adds an observer for vtkCommand::ModifyEvent.
*VtkSetAndObserveMRMLObjectEventsMacro - registers MRML node and adds an observer for a specified set of events.
*SetAndObserveMRMLScene[Events]() method is used in GUI and Logic to observe Modify, NewScene, NodeAdded, etc. events.
*ProcessMRMLEvents method should be implemented in MRML nodes, Logic, and GUI classes in order to process events from the observed nodes.

= Creating Custom MRML Node Classes=

*Custom MRML nodes provide persistent storage for the module parameters.
*Custom MRML nodes should be registered with the MRML scene using RegisterNodeClass() so they can be saved and restored from a scene file.
*Classes should implement the following methods:
*CreateNodeInstance() – similar to VTK New() method only not static.
*GetNodeTagName() – return a unique XML tag for this node.
*ReadXMLAttributes() – reads node attributes from XML file as name-value pairs.
*WriteXML() – writes node attributes to output stream (as in interpolate="1" ).
*Copy() – copies node attributes.

*If the node has references to other nodes the following additional methods should be implemented:
–UpdateReferenceID() - updates the stored reference to another node.
–UpdateScene()- updates other nodes in the scene depending on this node or updates this node if it depends on other nodes when the scene is read in.
This method is called automatically by XML parser after all nodes are created.
*An example of a custom MRML node implementation: vtkMRMLGradientAnisotropicDiffusionFilterNode in Modules/GradientAnisotropicDiffusionFilter directory.
*To add node to the MRML scene:
–In the code: use standard vtk New() and add node to the scene using vtkMRMLScene::AddNode(vtkMRMLNode *)
–By user request: use vtkSlicerNodeSelectorWidget that creates a new node from the module’s UI.

= Undo/Redo Mechanism =

*Undo/Redo is based on saving and restoring the state of MRML nodes in the Scene.
*MRML scene can save snapshot of all nodes into a special Undo and Redo stacks.
*The Undo and Redo stacks store copies of nodes that have changed from the previous snapshot. The node that have not changes are stored by a reference (pointer).
*When an Undo is called on the scene, the current state of Undo stack is copied into the current scene and also into Redo stack.
* All Undoable operations must store their data as MRML nodes

{|
|[[Image: Slicer3_MRML_Undo.jpg|thumb|400px]]
|}

*Developer controls at what point the snapshot is saved by calling SaveStateForUndo method on the MRML scene.
–SaveStateForUndo() - saves the state of all nodes in the scene
<br />–SetActiveScene(vtkMRMLScene *) - saves the state of the specified node.
<br />–SetActiveScene(vtkCollection*) - saves the state of the specified collection of nodes.
*SaveStateForUndo() should be called in GUI/Logic classes before changing the state of MRML nodes. Usually done in the ProcessGUIEvents method that processes events from the user interactions with GUI widgets.
*SaveStateForUndo() should not be called while processing transient events such as continuous events sent by KW UI while dragging a slider (for example vtkKWScale::ScaleValueStartChangingEvent).

The following methods on the MRML scene are used to manage Undo/Redo stacks:

* vtkMRMLScene::Undo() – restore the previously saved state of the MRML scene.
* vtkMRMLScene::Redo() – restore the previously undone state of the MREML scene.
* vtkMRMLScene::SetUndoOff() – ignore following SaveStateForUndo calls (usefull when making multiple changes to the scene/nodes that does not need to be undone).
* vtkMRMLScene::SetUndoOn() – enable following SaveStateForUndo calls.
* vtkMRMLScene::ClearUndoStack() – clears the undo history.
* vtkMRMLScene::ClearRedoStack() – clears the redo history.

Slicer Module developers should call vtkMRMLScne::SaveStateForUndo() method in their modules before changing the state of MRML nodes. This is usually done in the ProcessGUIEvents method that processes events from the user interactions with GUI widgets. Note, that vtkMRMLScne::SaveStateForUndo() method should not be called while processing transient events such as continuos events sent by UI while dragging a slider (for example vtkKWScale::ScaleValueStartChangingEvent).

= Other Useful References =

== MRML API Documentation ==

The detailed documentation of MRML API can be found in [http://www.na-mic.org/Slicer/Documentation/Slicer3/html/classes.html <nowiki> Slicer3 Doxygen pages</nowiki>]

== History ==

See Data Model notes in [[AHM_2006:ProjectsSlicerDataModel|AHM 2006 Programming week project]].

== Path-based MRML proposal ==

Mike's proposal for a [[Slicer3:MRML3_Path|path-based MRML3 representation]], based on extending the Coordinate Space Manager ideas to the entire MRML3 tree

== Slicer Daemon ==

The goal of the [[Slicer3:Slicer_Daemon|Slicer Daemon]] project is to allow remote editing of the MRML data model by external programs over a socket.

= Slicer 2.6 MRML =

== Data Represented in MRML in Slicer 2.6 ==

* Volumes
** IJK->RAS (VTK->RAS)
** Scalar Types
** Multicomponent (RGB, Displacement Vector)
** Tensor Volumes
** Label Maps
** Reference to Lookup Table

* Models
** vtkPolyData
*** Named Field Data (scalars, vectors, labels) at points and cells (FreeSurferReaders)
*** Polylines with tensor point data (DTMRI Module)
** Color, Clipping State, Visibility, Scalar Visibility, LookupTable

* Transforms
** Matrix4x4

* Lookup Tables
** vtkLookupTable info

* Fiducials
** Position, Quaternion
** Name, Selection State, Type (endoscopic, normal)
** Glyph Size, Text Size

* Fiducial Lists
** Name, Slze, Color, Selection State

* Colors
** Name, Label#, Diffuse/Ambient/Specular

* Model Groups

* Application State (not to be carried to Slicer3 MRML)
* Locator (not to be carried to Slicer3 MRML)
* Module Specific Parameters (not to be carried to Slicer3 MRML)

<br />

== Operations On MRML Scene ==

* Load from File
* Save to File
* Traverse Nodes in Tree
* Insert Node
* Delete Node
* Register Tree Observer
* Update MRML
* Get Transformations (e.g. IJK to World through transform tree)

* Data Type Specific Operations
** Get/Set Node MetaData
** Get/Set Data (e.g. as vtkImageData)

== General References on XML ==

A wikibook on XML: http://en.wikibooks.org/wiki/XML:_Managing_Data_Exchange

The section on ID/IDREF implementations which are similar to what we use in MRML: http://en.wikibooks.org/wiki/XML:_Managing_Data_Exchange/The_many-to-many_relationship#ID.2FIDRE

Slicer3:Data Model

2007-05-24T13:02:36Z

Mathieu: /* MRML API Documentation */

= Slicer3 MRML Overview =

*MRML Library provides API for managing medical image data types (Volumes, Models, Transforms, Fiducials, Cameras, etc) and their visualization.
*Each data type is represented by a special MRML node.
*MRML Scene is a collection of MRML nodes.
*Slicer MRML data model is implemented independent of the visualization and algorithmic components of the system.
*Other Slicer components (Logic and GUI) observe changes in MRML scene and individual nodes and process change MRML events.

For more details on MRML architecture see [http://www.na-mic.org/Wiki/images/e/e3/Slicer_3-alpha-2006-04-03.ppt Architecture Slides].

= MRML Scene =

*MRML Scene manages MRML nodes : add, delete, find, find by type, etc.
*MRML Scene provides persistence of MRML nodes (reading/writing to/from XML file).
*MRML Scene provides Undo/Redo mechanism that restores a previous state of the scene and individual nodes.

= MRML Nodes =

*The MRML nodes are designed to store the state of the Slicer application, both raw data and visualization parameters.

There following is a set of core MRLN nodes that store the state of core Slicer modules:

* vtkMRMLCameraNode
* vtkMRMLClipModelsNode
* vtkMRMLSliceCompositeNode
* vtkMRMLSliceNode
* vtkMRMLColorNode
* vtkMRMLTransformNode
* vtkMRMLLinearTransformNode
* vtkMRMLTransformableNode
* vtkMRMLFiducialListNode
* vtkMRMLModelNode
* vtkMRMLModelDisplayNode
* vtkMRMLStorageNode
* vtkMRMLModelStorageNode
* vtkMRMLVolumeNode
* vtkMRMLScalarVolumeNode
* vtkMRMLVectorVolumeNode
* vtkMRMLTensorVolumeNode
* vtkMRMLDiffusionTensorVolumeNode
* vtkMRMLDiffusionWeightedVolumeNode
* vtkMRMLVolumeDisplayNode
* vtkMRMLVectorVolumeDisplayNode
* vtkMRMLDiffusionTensorVolumeDisplayNode
* vtkMRMLDiffusionWeightedVolumeDisplayNode
* vtkMRMLVolumeHeaderlessStorageNode
* vtkMRMLVolumeArchetypeStorageNode

<br />
*MRML nodes are organized into C++ class hierarchies, all derived from vtkMRMLNode class.
*For example vtkMRMLTransformableNode is the parent class of Volume, Model, Fiducial, and Transformation nodes; vtkVolumeNode is a parent of vtkMRMLScalarVolumeNode and vtkMRMLVectorVolumeNode
*All MRML nodes have to implement certain standard API: ReadAttributes, WriteAttributes, Copy, etc.
{|
|[[Image: Slicer3_MRML_Node_Hier.jpg|thumb|400px]]
|}

= References to MRML Nodes =

*Some MRML nodes have references to other nodes.
*Transformable Node has a reference to a Transformation node. Transformation node has a reference to its parent Transformation node.
*References are stored by node ID.
*Use vtkSetReferenceStringMacro to set reference ID (it registers reference with the scene).
*Access methods should check if the referenced node is still in the MRML scene using its ID.
{|
|[[Image: Slicer3_MRML_Trans_Ref.jpg|thumb|400px]]
|}

= MRML Events and Observers =

*Changes in MRML scene and individual nodes propagate to other observing nodes, GUI and Logic objects via vtk events and command-observer mechanism.
*Use vtk AddObserver() and InvokeEvent() methods. vtk SetMacro generates ModifiedEvent.
*The command-observer mechanism for MRML is implemented using helper vtkObserverManager, class, MRML Observer macros, and ProcessMRMLEvents method.
*Observers should store a registered pointer to a MRML node to prevent callbacks on a deleted object.
{|
|[[Image: Slicer3_MRML_Observ.jpg|thumb|400px]]
|}

*MRML observer macros are defined in Libs/MRML/vtkMRMLNode.h
*VtkSetMRMLObjectMacro - registers MRML node with another vtk object (another MRML node, Logic or GUI). No observers added.
*VtkSetAndObserveMRMLObjectMacro - registers MRML node and adds an observer for vtkCommand::ModifyEvent.
*VtkSetAndObserveMRMLObjectEventsMacro - registers MRML node and adds an observer for a specified set of events.
*SetAndObserveMRMLScene[Events]() method is used in GUI and Logic to observe Modify, NewScene, NodeAdded, etc. events.
*ProcessMRMLEvents method should be implemented in MRML nodes, Logic, and GUI classes in order to process events from the observed nodes.

= Creating Custom MRML Node Classes=

*Custom MRML nodes provide persistent storage for the module parameters.
*Custom MRML nodes should be registered with the MRML scene using RegisterNodeClass() so they can be saved and restored from a scene file.
*Classes should implement the following methods:
*CreateNodeInstance() – similar to VTK New() method only not static.
*GetNodeTagName() – return a unique XML tag for this node.
*ReadXMLAttributes() – reads node attributes from XML file as name-value pairs.
*WriteXML() – writes node attributes to output stream (as in interpolate="1" ).
*Copy() – copies node attributes.

*If the node has references to other nodes the following additional methods should be implemented:
–UpdateReferenceID() - updates the stored reference to another node.
–UpdateScene()- updates other nodes in the scene depending on this node or updates this node if it depends on other nodes when the scene is read in.
This method is called automatically by XML parser after all nodes are created.
*An example of a custom MRML node implementation: vtkMRMLGradientAnisotropicDiffusionFilterNode in Modules/GradientAnisotropicDiffusionFilter directory.
*To add node to the MRML scene:
–In the code: use standard vtk New() and add node to the scene using vtkMRMLScene::AddNode(vtkMRMLNode *)
–By user request: use vtkSlicerNodeSelectorWidget that creates a new node from the module’s UI.

= Undo/Redo Mechanism =

*Undo/Redo is based on saving and restoring the state of MRML nodes in the Scene.
*MRML scene can save snapshot of all nodes into a special Undo and Redo stacks.
*The Undo and Redo stacks store copies of nodes that have changed from the previous snapshot. The node that have not changes are stored by a reference (pointer).
*When an Undo is called on the scene, the current state of Undo stack is copied into the current scene and also into Redo stack.
* All Undoable operations must store their data as MRML nodes

{|
|[[Image: Slicer3_MRML_Undo.jpg|thumb|400px]]
|}

*Developer controls at what point the snapshot is saved by calling SaveStateForUndo method on the MRML scene.
–SaveStateForUndo() - saves the state of all nodes in the scene
<br />–SetActiveScene(vtkMRMLScene *) - saves the state of the specified node.
<br />–SetActiveScene(vtkCollection*) - saves the state of the specified collection of nodes.
*SaveStateForUndo() should be called in GUI/Logic classes before changing the state of MRML nodes. Usually done in the ProcessGUIEvents method that processes events from the user interactions with GUI widgets.
*SaveStateForUndo() should not be called while processing transient events such as continuous events sent by KW UI while dragging a slider (for example vtkKWScale::ScaleValueStartChangingEvent).

The following methods on the MRML scene are used to manage Undo/Redo stacks:

* vtkMRMLScene::Undo() – restore the previously saved state of the MRML scene.
* vtkMRMLScene::Redo() – restore the previously undone state of the MREML scene.
* vtkMRMLScene::SetUndoOff() – ignore following SaveStateForUndo calls (usefull when making multiple changes to the scene/nodes that does not need to be undone).
* vtkMRMLScene::SetUndoOn() – enable following SaveStateForUndo calls.
* vtkMRMLScene::ClearUndoStack() – clears the undo history.
* vtkMRMLScene::ClearRedoStack() – clears the redo history.

Slicer Module developers should call vtkMRMLScne::SaveStateForUndo() method in their modules before changing the state of MRML nodes. This is usually done in the ProcessGUIEvents method that processes events from the user interactions with GUI widgets. Note, that vtkMRMLScne::SaveStateForUndo() method should not be called while processing transient events such as continuos events sent by UI while dragging a slider (for example vtkKWScale::ScaleValueStartChangingEvent).

= Other Useful References =

== MRML API Documentation ==

The detailed documentaion of MRML API can be found in [http://www.na-mic.org/Slicer/Documentation/Slicer3/html/classes.html <nowiki> Slicer3 Doxygen pages</nowiki>]

== History ==

See Data Model notes in [[AHM_2006:ProjectsSlicerDataModel|AHM 2006 Programming week project]].

== Path-based MRML proposal ==

Mike's proposal for a [[Slicer3:MRML3_Path|path-based MRML3 representation]], based on extending the Coordinate Space Manager ideas to the entire MRML3 tree

== Slicer Daemon ==

The goal of the [[Slicer3:Slicer_Daemon|Slicer Daemon]] project is to allow remote editing of the MRML data model by external programs over a socket.

= Slicer 2.6 MRML =

== Data Represented in MRML in Slicer 2.6 ==

* Volumes
** IJK->RAS (VTK->RAS)
** Scalar Types
** Multicomponent (RGB, Displacement Vector)
** Tensor Volumes
** Label Maps
** Reference to Lookup Table

* Models
** vtkPolyData
*** Named Field Data (scalars, vectors, labels) at points and cells (FreeSurferReaders)
*** Polylines with tensor point data (DTMRI Module)
** Color, Clipping State, Visibility, Scalar Visibility, LookupTable

* Transforms
** Matrix4x4

* Lookup Tables
** vtkLookupTable info

* Fiducials
** Position, Quaternion
** Name, Selection State, Type (endoscopic, normal)
** Glyph Size, Text Size

* Fiducial Lists
** Name, Slze, Color, Selection State

* Colors
** Name, Label#, Diffuse/Ambient/Specular

* Model Groups

* Application State (not to be carried to Slicer3 MRML)
* Locator (not to be carried to Slicer3 MRML)
* Module Specific Parameters (not to be carried to Slicer3 MRML)

<br />

== Operations On MRML Scene ==

* Load from File
* Save to File
* Traverse Nodes in Tree
* Insert Node
* Delete Node
* Register Tree Observer
* Update MRML
* Get Transformations (e.g. IJK to World through transform tree)

* Data Type Specific Operations
** Get/Set Node MetaData
** Get/Set Data (e.g. as vtkImageData)

== General References on XML ==

A wikibook on XML: http://en.wikibooks.org/wiki/XML:_Managing_Data_Exchange

The section on ID/IDREF implementations which are similar to what we use in MRML: http://en.wikibooks.org/wiki/XML:_Managing_Data_Exchange/The_many-to-many_relationship#ID.2FIDRE