NAMIC Wiki:DTI:DICOM for DWI and DTI
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 here.
As long DICOM support for DWI information is vendor-specific and/or non-conformant with the info here, the Nrrd format provides a means of recording the DWI-specific information once it is known.
Contents
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 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 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 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:
(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 ...
Ref:
Update
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:
[Y I] = max(BMtx([1 4 6])); % Avoid using a zero cross-term (credits to Phil Cook)
switch I
case 1
BSign = sign(BMtx(1:3)); % Assume bx is positive
case 2
BSign = sign(BMtx([2 4 5])); % Assume by is positive
case 3
BSign = sign(BMtx([3 5 6])); % Assume bz is positive
end
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
in particular:
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
DICOM for estimated diffusion tensors
There is no specification right now in DICOM to support Tensor. Only a supplement:
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
