It depends on how you get your images in the first place. If you use
mri_convert to convert from dicom files, then it uses information in the
dicom header. I'm attaching the rules that mri_convert uses. If you get
your data from somewhere else, then mri_convert will try to find the
orientation information in the header, if it is there. In minc and
nifti, it is imbedded. If you have spm-analyze, then there should be a
.mat file with the geometry info. In that case, the orientation is only
as accurate as it is in the source file. In tkmedit, the images are
always displayed LR reversed (ie, the right side of the image is the
left side of the subject); there are axes you can turn on to show this.
If you want to double check, then put a fiducial on your subject next
time you scan and see where it ends up in the image (you should be doing
this anyway).
doug
Chacko Cherian wrote:
Hello everyone,
orientation i guess is quite an issue.
Well how does,Freesurfer determine orientation of the
image.Do I have to know how the image has been
processed before it reaches me or is there any other
way to find out?Does it have to do with the 'flip'?
I checked the orientation of an image on SPM and on
Freesurfer.
Left on SPM is Right on Freesurfer and vice versa is
what I got.
Essentially how do I determine L-R orientation?
Thanks in advance,
Chacko Cherian.
Arizona State University.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
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
currently uses to determine them:
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
