1. the dicom standard is LPS (left-post-sup), we use RAS, so the xy components are negated. 2. Very slowly. Below are the rules that I used to compute the geometry use by mri_convert, including how to go from mosaics.
doug
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".
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).
Chris Adamson wrote:
Hello all,
I'm wondering how mri_convert computes the centre of the image (shown as ImgPos in the output of mri_convert).
I have two questions:
- I had a non-mosaic SIEMENS format DICOM volume and ImgPos was copied from (0x0020,0x0032) DS Image Position (Patient), but the X and Y values are negated, why is that?
- How does mri_convert compute ImgPos for mosaic format SIEMENS DICOM files?
Thanks in advance,
Chris.