Critical Parameters for a given series, and the rules Doug Greve
(greve@nmr.mgh.harvard.edu) currently uses to determine them. If you
use this info, please give me some credit -- it took a long time to
figure out:).
Non-DICOM tags are found in proprietary Siemens fields. While
proprietary, these are stored as simple ASCII text surrounded by the
strings "### ASCCONV BEGIN ###" and "### ASCCONV END ###", so it is
easy to parse them with simple string operations (ie, you don't need
to get into the dicom stuff). I refer to this as the "ASCII header"
below.
1. Files that belong to a series.
Read the series number from the DICOM header (20,11). This
apparently won't work when "Multiple Series" is checked.
2. Whether each file contains an individual image, a mosaic, or
supermosaic.
I use the Phase Encode FoV ("sSliceArray.asSlice[0].dPhaseFOV") and
the Readout FoV ("sSliceArray.asSlice[0].dReadoutFOV") from the
ASCII header, the Phase Encode Direction (18,1312), and the row and
column resolutions (28,30) to compute an expected number of rows
and columns. I then compare these numbers to the number of rows
(28,10) and columns (28,11) in the image. If they are the same, then
it is not a mosaic or supermosaic. If they are not, I assume it's a
mosaic. I don't know how to tell if its a supermosaic.
3. If a file contains a mosaic, the number of rows and cols in the
mosaic.
This is just the number of rows (28,10) and columns (28,11) in the
image.
4. If a file contains a supermosaic, the number of mosaics in the
super mosaic (as well as the dimension of each mosaic). ???
5. Volume dimensions (ie, number of rows, columns, slices).
a. Non-mosaics - the number of rows and columns are determined
directly from the DICOM header ((28,10) and (28,11)). The number of
slices is determined by counting the number of files in the series
with different slice prescriptions.
b. Mosaics - the number of rows and columns are determined from the
Phase Encode and Readout FoVs as described in #2. The number of
slices is determined from the ASCII header (sSliceArray.lSize).
c. Supermosaics - ???
6. Volume resolution (ie, distance between the centers of adjacent
rows, cols, and slices).
For rows and columns, the resolutions are obtained from DICOM
(28,30), which is a string of the form "colres\rowres". The
distance between slices is obtained from DICOM (18,88). If that
does not exist, then the slice thickness (18,50) is used, but this
will not include the distance factor or gap. Supposedly, the skip
can be obtained from (21,1344), but special software is needed to
read odd DICOM groups. There is also an element in the ASCII header
("sGroupArray.asGroup[0].dDistFact"). One can also compute the
slice resolution as the distance between adjacent slices using
"sSliceArray.asSlice[N].sPosition.dAAA" where AAA is Sag (x), Cor
(y), and Tra (z) from the ASCII header.
7. The direction cosines (DCs) for the row, col, and slice.
The DCs for the row and column are obtained from DICOM (20,37),
which is a string of the form "cx\cy\cz\rx\ry\rz". The slice DC is
obtained from the ASCII header. The x, y, and z components are from
three lines of the form "sSliceArray.asSlice[0].sNormal.dAAA" where
AAA is Sag (x), Cor (y), and Tra (z). Siemens may reverse the slice
order in order to make the images more readable by
radiologists. This reversal is NOT accompanied by a change the
slice direction cosine. Rather, it is indicated by the presence of
sSliceArray.ucImageNumbAAA (any of the three). The FreeSurfer
software reverses the slices upon read-in rather than chaning
the direction cosine.
8. The XYZ coordinates at the exact center of a voxel at a given row,
col, and slice.
a. Non-mosaics - DICOM (20,32) gives the XYZ coordinate at the
center of first voxel of the image. Section C.7.6.2.1.1, page 275:
"The Image Position (0020,0032) specifies the x, y, and z
coordinates of the upper left hand corner of the image; it is the
center of the first voxel transmitted."
b. Mosaics - DICOM (20,32) is incorrect for mosaics. The value in
this field gives where the origin of an image the size of the
mosaic would have been had such an image been collected. This puts
the origin outside of the scanner. However, the center of a slice
can be obtained from the ASCII header from lines of the form
"sSliceArray.asSlice[N].sPosition.dAAA", where N is the slice
number and AAA is Sag (x), Cor (y), and Tra (z). This may be off by
half a voxel. Given this information, the direction cosines, the
voxel size, and dimension, the origin can be computed.
c. Supermosaics - ???
9. Number of Volumes (ie, number of frames or time points).
a. Non-mosaics - count the number of files with the same image
position.
b. Mosaics - count the number of files in the series. The number
of frames should also be stored in the ASCII header as 1 plus
lRepetitions.
c. Supermosaics - ???
10. Time between volumes/frames (ie, the TR for fMRI).
a. Non-mosaics - ???
b. Mosaics - number of slices times the repetition time (DICOM
(18,80)). This is for version 1.6 and before. For version 2.1
and after, (18,80) will contain the inter-volume TR (instead
of the time it takes to acquire one slice). The software version
can be determined from tag (18,1020)
c. Supermosaics - ???
11. Time at which each slice was obtained (relative to the start of
the volume acquisition). For sequences in which slices were
acquired uniformly across the TR, there is a variable in the ASCII
header called sSliceArray.ucMode which indicates the slice order:
0x1 for Ascending, 0x2 for Descending, and 0x4 for Interleaved.
The selection box for this option can be found on the Numaris/4
GUI on the "Geometry" tab, "Common" sub-tab, field name "Series".
[NEED TO VERIFY THIS] If sSliceArray.ucImageNumbTra (or Cor or
Sag) is greater than zero, for axial data (or coronal or sagittal,
respectively) then we know the slice order is reversed from what
was expected (ie, that set up on the console).
12. Time at which each volume was obtained (relative to the start of the
series). This may not be computable from the slice timing if
there is a temporal gap between volumes. ??? See also below on
slice timing.
13. Other parameters not so critical: echo time, inversion time, phase
encode direction, readout direction, flip angle, patient name,
scan date, scan time, pulse sequence, protocol name, etc. These
are obtainable from the DICOM header.
NOTE ON COORDINATE DEFINITION. It is assumed that all xyz coordinates
(including direction cosines) in the Siemens DICOM header (including
ASCII) conform to an LPS standard. "LPS" means that x increases from
the subject's right to Left, y increases from anterior to Posterior,
and z increases from inferior to Superior. All this assumes that the
subject in the scanner Head-First/Supine (HFS). The patient's position
can be determined from DICOM tag (18,5100). It appears that this
definition can be changed from the Numaris 4 console. On the "System"
tab, "Common" sub-tab, heading "Image Numbering" there are selections
for fields "Sagittal", "Coronal", and "Transversal". Changes these
parameters will affect the variable called
sSliceArray.ucImageNumb{Sag,Cor,Tra} in the ASCII header. The value
will be either 0 or 0x1 (NOTE: a value of 0 is indicated by the
absence of the variable in the header).
---------------------------------------------------------------------------
MGH's dicom server (bourget)
For reference, our naming scheme to date has used the following
dicom tags which has so far guaranteed uniqueness:
d 0008 1090 modelX
d 0018 1000 serialX
d 0008 0020 dateX
D 0008 0030 timeX
f 0020 0011 seriesX
F 0020 0013 imageX
If we add to this, it will change the names of all scanner files
henceforth. Any analysis tools that "depend" on the name scheme will
have to be modified to handle both old and new.
---------------------------------------------------------------------------
Image Type: 0008 0008 - might tell you if it is a mosaic
Anat: DERIVED\PRIMARY\OTHER
Func: ORIGINAL\PRIMARY\M\ND\MOSAIC
M = magnitude. P = phase.
-------------------------------------------------------------------------
From Siemens white paper: "Slice Order (Slice Timing) for fMRI
Evaluation Joachim Graessner, Dipl. Ing." Dated May 2014
The EPI mosaic in figure 6 shows a series containing 36/35 interleaved
measured slices with text overlays for image numbers, excitation order
number and relative offset time. The latter value can be extracted
from the DICOM header in tag (0019,1029) „MosaicRefAcqTimes“ together
with tag (0008,0032) „Acquisition time“ to calculate the absolute time
of an image.
---------------------------------------------------------------------------
(0008,0013) TM [171809.637000] # 14, 1 InstanceCreationTime
(0008,0020) DA [20111006] # 8, 1 StudyDate
(0008,0021) DA [20111006] # 8, 1 SeriesDate
(0008,0022) DA [20111006] # 8, 1 AcquisitionDate
(0008,0023) DA [20111006] # 8, 1 ContentDate
(0008,0030) TM [165732.988000] # 14, 1 StudyTime
(0008,0031) TM [171609.633000] # 14, 1 SeriesTime
(0008,0032) TM [171736.510000] # 14, 1 AcquisitionTime
(0008,0033) TM [171809.637000] # 14, 1 ContentTime
Time
A string of characters of the format hhmmss.frac; where hh contains
hours (range "00" - "23"), mm contains minutes (range "00" - "59"), ss
contains seconds (range "00" - "59"), and frac contains a fractional
part of a second as small as 1 millionth of a second (range "000000" -
"999999"). A 24 hour clock is assumed. Midnight can be represented by
only "0000" since "2400" would violate the hour range. The string may
be padded with trailing spaces. Leading and embedded spaces are not
allowed. One or more of the components mm, ss, or frac may be
unspecified as long as every component to the right of an unspecified
component is also unspecified. If frac is unspecified the preceding
"." may not be included. Frac shall be held to six decimal places or
less to ensure its format conforms to the ANSI HISPP MSDS Time common
data type.
Examples -
1. "070907.0705" represents a time of 7 hours, 9 minutes and 7.0705 seconds.
2. "1010" represents a time of 10 hours, and 10 minutes.
3. "021" is an invalid value.
Note -
1. For reasons of backward compatibility with versions of this
standard prior to V3.0, it is recommended that implementations also
support a string of characters of the format hh:mm:ss.frac for this
VR.
--------------------------------------------------------------
the pixel data cannot be loaded as it is JPEG compressed
dcmdjpeg +te $dcm $dcm
---------------------------------------------------
GE
0x0043, 0x1039 bvalue
0x0019, 0x10bb, 0x10bc, 0x10bd directions
--------------------------------------------------------------
https://github.com/BRAINSia/BRAINSTools/blob/master/DWIConvert/SiemensDWIConverter.h
bvalue 0x0019 0x100c
bvector 0x0019 0x100e
bmatrix 0x0019 0x1027
diffusion info 0029,1010
If zero, then tags do not exist.
For bay1 dti data, the bvalues are correct. The x for the bvector is
correct. The yz need to be negated. Even then, they are not quite
correct. bmatrix is the 6 elements used to create the bmatrix and
appears to be redundant (does not resolve above issue). Diffusion info
apparently also has the directions but also appears to be redundant.
bvalue in 0x100a does not match trace(bmatrix) or value that AY gave
me. The difference is due to obliqueness; not clear what the right
answer is.
dnggrad = load('dnggrad.txt');
bvals0 = load('bvals.txt')';
bvecs0 = load('bvecs.txt')';
indnz = find(bvals0 ~= 0);
bvals = bvals0(indnz);
bvecs = bvecs0(indnz,:);
gm = load('grad.mtx.dat');
ntot = size(gm,1);
d = zeros(ntot,3);
db = zeros(ntot,1);
for n = 1:ntot
a = gm(n,:);
b = zeros(3,3);
b(1,1) = a(1);
b(1,2) = a(2);
b(1,3) = a(3);
b(2,2) = a(4);
b(2,3) = a(5);
b(3,3) = a(6);
b(3,1) = b(1,3);
b(2,1) = b(1,2);
b(3,2) = b(2,3);
[u s v] = svd(b);
d(n,:) = u(:,1)';
db(n) = trace(b);
end
-----------------------------------------------------------------
Double oblique data in ~/l/sg1/oblique-dti.
This data does not have the above fields but does have
DiffusionGradientDirection in the info header field (strings).
The gradients in the header do not match the gradients in the
mgh-dti-seqpack. The mgh-dti-seqpack parameters do not give good
results, but the ones from the header do. Though the acqs for all
three had the same slice prescription, the header gradient directions
are slightly different.
----------------------------------------------------------------------------
our current software is RSNA CTN (central test node) produced by the
Mallinckrodt Institute of Radiology (MIR) under contract to the
Radiological Society of North America.
ftp://wuerlim.wustl.edu/pub/dicom/software/ctn/ says there should be a
docs folder but can't be found bugs: dicom_bugs@wuerl.wustl.edu
https://www.mir.wustl.edu/Portals/0/Documents/Uploads/ERL/users-guide.pdf
-------------------------------------------------------------
http://www.dicomtags.com/vrs
IS - integer string, 12 bytes max
OB - other byte string, unlimited.
LO - Long String 64 Bytes Maximum
-----------------------------------------
Doc for GE that might be helpful for understanding their dicoms
https://www.gehealthcare.com/-/jssmedia/widen/2018/01/25/0204/gehealthcarecom/migrated/2018/02/19/0841/ability-dicom-magnetic-resonance-gehc-dicom-conformance_discoverymr450_doc0506131_rev3_pdf.pdf?rev=-1&hash=FD53D6AC70B532F200FA14C33E84C7EF
-----------------------------------------
itk::DCMTKSequence originSeq;
curItem.GetElementSQ(0x0020, 0x9113, originSeq);
std::string originString;
originSeq.GetElementDS(0x0020, 0x0032, originString);
ftp://ftp.philips.com/pub/pms-3003/DICOM_Information/CookBook.pdf
18,88 - slice spacing
20,37 - image orientation patient
28,30 - pixel spacing
(0028,1052) DS [0] # 2, 1 RescaleIntercept
(0028,1053) DS [1.23785103785103] # 16, 1 RescaleSlope
(0028,1054) LO [US] # 2, 1 RescaleType
5200,9229 - functional group macro whose attributes apply to all frames
5200,9230 - functional group macro whose attributes apply to a given frames
---------------------------------------------------------
On-scanner gradient distortion correction
In the protocol, one has the option to not do any gradient
nonlinearity correction (default), 2D correction, or 3D correction
(even with 2D data but it requires at least 8 slices from the same
scan in the same orientation). Whether or not correction was used on
the data will be in the Siemens private header.
Specifically in (0029,1020)
sDistortionCorrFilter.ucMode = 1 (none, or "ND")
sDistortionCorrFilter.ucMode = 2 (2D, or "DIS2D")
sDistortionCorrFilter.ucMode = 4 (3D, or "DIS3D")
Also, it is derived and can be also found in the image labeling header section as
(0051,1016) = LO 000018 p2 NORM/MEAN/DIS3D (or DIS2D or ND)
0008,0008 also has info like above
======================================================================
Explaining unpacking of bvecs. Different manufactures have different
conventions. Siemens puts the bvecs in LPS scanner space. To map them
to voxel space, they should be converted to RAS scanner space, then
multiplied by the inverse of the Mdc part of the vox2ras matrix (to
convert from ras to vox).
The field has evolved using the "FSL" standard. In FSL, if the
determinant>0 (neurological), then an FSL program flips the image in
the first dimension to make the determinant<0 (radiological). The
program performs its processing, then flips any output volume back to
the original space before writing it out. For most things, this is ok,
but for DTI processing, reorienting the image must be matched by
reorienting the bvecs. FSL should have just done this when seeing that
the image needed to be reoriented, but instead it requires the user to
know that the image will be reoriented and supply FSL witha reoriented
bvec file. So, when det<0, the bvec orientation matches that of the
input volume. When det>0, the sign of the first bvec has to be
flipped. Note that the sign of all bvec values can be reversed without
changing the output. On the output side, none of this matters for FA,
but it does matter for the eigen vectors. For det>0 volumes, the EVs
written out by FSL will be inconsistent with the volume orientation
(eg, in FreeView they will look wrong). However, an FSL viewer
(eg, fsleyes), will see det>0 and then reorient the EVs so they are
correct.
Here are two related discussions:
https://github.com/rordenlab/dcm2niix/issues/269
https://github.com/rordenlab/dcm2niix/issues/366
https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FDT/FAQ#What_conventions_do_the_bvecs_use.3F
In the connectome data:
dcm2niix: PSL (det>0) +--
DNG/FS: PIL (det<0) -+-
Going from PSL to PIL or back requires:
1. the sign of the 2nd to be flipped because the dimension is flipped
2. the sign of the 1st to be flipped because det changes sign
Analyzing the PIL data with both FS mri_glmfit and FSL dtifit with the
same bvecs gives the same result because the det<0.
Analysing the PIL data in FSL with the dcm2niix bvecs yields correct
results (must be viewing in fsleyes). When analyzing the PIL data in
FS mri_glmfit using the dcm2niix bvecs, the sign of the first bvec
needs to be flipped. Then the result will look correct when viewing in
FreeView.