I've attached the rules that freesurfer uses to extract the geometry
info from siemens dicom files. For EPIs, you have to read the shadow
field (stored as plain text). Look at these slides for how to
automatically create registrations from the header:
https://surfer.nmr.mgh.harvard.edu/fswiki/CoordinateSystems?action=AttachFile&do=view&target=fscoordinates.ppt
doug
Alexander Gussew wrote:
Dear Sir or Madam,
In our institution we try to implement an automatic routine for the
co-registration of MRI images and 3 dimensional MR spectroscopic
metabolic maps acquired on SIEMENS MR Scanner. We try to realize it by
using the Dicom reading function as implemented in MATLAB.
To evaluate the transformation matrix extracted from the DICOM header
tag “ImageOrientationPatient” we compared it with the matrix
extracted by tool “tkregister2”contained in the freesurfer package.
Because of some observed obscurities we would like to ask you following
questions:
1) How does tkregister2 rebuild the transformation matrix of the
corresponding Nifti-file (inversion?) which is used in the
freesurfer-tool “flirt” for the coregistration (the matrix in the
file with the extension .fsl)?
2) Is the order of rotations performed by the data acquisition relevant
for the several steps of matrix construction? If so is there a general
way how ‘tkregister2’ extract this order and consider for the
further calculations?
3) By the reading and plotting the 3D DICOM image data sets with MATLAB
we figured out, that directions of several spaces axes are changing
(negativepositive; positivenegative) depending on the image
orientation using during the acquisition (sagital, coronar,
transversal). We guessed that we should at first correct our data by
flipping some axes (e.g. in sagital case LR-axis) and then apply the
matrix extracted from DICOM-header to the corrected data set. If it is
correct how ‘tkregister2’ tool perform this correction for several
orientation cases?
With best regards,
Alexander Gussew
Medical Physics Group
Instut for Diagnostic and Interventional Radiology
Hospital of Friedrich-Schiller-University Jena, Germany
Dipl.-Ing. Alexander Gussew
Institut für Diagnostische und Interventionelle Radiologie
AG Medizinische Physik
Klinikum der Friedrich-Schiller-Universitaet Jena
Philosophenweg 3
D-07743 Jena
Germany
Tel. +49 (0)3641 935361
Fax +49 (0)3641 936767
e-mail: [EMAIL PROTECTED]
____________________
Universitätsklinikum Jena
Körperschaft des öffentlichen Rechts und Teilkörperschaft der
Friedrich-Schiller-Universität Jena
Bachstraße 18, 07743 Jena
Verwaltungsratsvorsitzender: Prof. Dr. Walter Bauer-Wabnegg;
Medizinischer Vorstand: Prof. Dr. Klaus Höffken;
Wissenschaftlicher Vorstand: Prof. Dr. Klaus Benndorf; Kaufmännischer
Vorstand und Sprecher des Klinikumsvorstandes Rudolf Kruse
Bankverbindung: Sparkasse Jena; BLZ: 830 530 30; Kto.: 221;
Gerichtsstand Jena
Steuernummer: 161/144/02978; USt.-IdNr. : DE 150545777
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
--
Douglas N. Greve, Ph.D.
MGH-NMR Center
[EMAIL PROTECTED]
Phone Number: 617-724-2358
Fax: 617-726-7422
In order to help us help you, please follow the steps in:
surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
Critical Parameters for a given series, and the rules Doug Greve
([EMAIL PROTECTED]) 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
first voxel of the image.
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".
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. ???
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.
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
