By direction I mean for example from a patient's head to bottom or from his bottom to head. The CHEST CT scans I have seen so far indicates that Instance Number 1 slice is usually the first one down from the upper part of the body but I don't know whether this is part of the standard or there are some other tags that I should inspect into to determine.
3 Answers
There is no rule in DICOM that requires the Instance Number to be related to the slice position in a particular way. The link of Bartloimiej shows that there is a rule how the slice coordinates defined by Image Position Patient (0020,0027) and Image Orientation Patient (0020, 0037) are related to directions in the patient's body (head, feet, etc.)
So if you want to apply spatial ordering, these attributes are what you want to use. Slice Location (0020,1041) will not help you as well:
C.7.6.2.1.2 [...] This information is relative to an unspecified implementation specific reference point.
For original (i.e. Image Type (0008,0008) is ORIGINAL\PRIMARY...) CT slices, it is quite safe to assume that some growth in the Z-Direction is always present in a volumetric dataset. But for MRI or for reconstructed CT-slices (MPR), you may find datasets in which slices are parallel to the xz or yz plane. If your application is supposed to handle such images, make sure to avoid division by zero...

- 3,916
- 14
- 32
-
The reason I care about instance number is that some sort of annotations (e.g. lung nodules) are organized by the dcm file names and I want to find their spatial locations i.e. voxel coordinate. The xy coordinates is already given in the annotation then it seems convenient if an instance number z (read from the dcm file) is mapped to the z-th slice in from one end. However it seems that the instance number has nothing to do with the ordering. – user1206899 Feb 14 '18 at 01:44
-
Correct, there may be a correllation between the z-coordinate and the instance number, but that would be unreliable. Having z = Slice Number would be exceptional, for it expects the z coordinates to grow by 1. Having annotations referring to filenames is blatantly contradictory to the basic concepts of DICOM. E.g. there is no way to convey the file name when the image is transferred through a socket. So this approach will work on one machine and no where else. – Markus Sabin Feb 14 '18 at 06:52
Yes, the standard defines it. DICOM PS3.3, part C.7.6.2:
The direction of the axes is defined fully by the patient's orientation.
If Anatomical Orientation Type (0010,2210) is absent or has a value of BIPED, the x-axis is increasing to the left hand side of the patient. The y-axis is increasing to the posterior side of the patient. The z-axis is increasing toward the head of the patient.
There is also a tag (0020,0037), Image Orientation (Patient)
, which relates actual position of the patient to the global coordinate frame. In trunk CT it is almost always 1 0 0 0 1 0
(no rotation) and you don't need to deal with it. Otherwise, see comments under the link above.

- 10,274
- 3
- 79
- 79

- 1,068
- 1
- 14
- 23
-
1I think the original question is regarding instance numbers, not patient positions. I don't think there is any requirement of instance number ordering, only that they are unique (excluding from the part which specifies the instance type). – Dženan Feb 10 '18 at 16:30
-
OK, but how would you know, what is the order of instances while you slice through the series? That's third value (Z) of Image Position (20,32), on which the order depends. And as I understand, OP asks, if increasing value of Z always comes from the feet to the head. – Bartłomiej Feb 10 '18 at 20:09
-
-
2The instance number doesn't have to be unique. It's usually just an integer (1, 2, 3, ...), might not be present, and doesn't tell you anything about the ordering of the images. – Tom Feb 12 '18 at 07:23
-
You can also have images with different Image Orientation Patient tags, even in a standard CT — for example localisers might get saved in the same series. So in general you would check that tag to filter out images that don't have matching Image Orientation Patient before assembling the series. – Tom Feb 12 '18 at 07:30
-
1Thank's for the discussion, I have misunderstood original question a little. Of course neither Instance Numbers (0020,0013) nor file names of instances are relevant to the ordering. My point was that Z axis has its direction defined, but apparently the question's subject was different. – Bartłomiej Feb 12 '18 at 09:11
-
Thanks for the explanations. The reason I care about instance number is that some sort of annotations (e.g. lung nodules) are organized by the dcm file names and I want to find their spatial locations i.e. voxel coordinate. The xy coordinates is already given in the annotation then it seems convenient if an instance number z (from the dcm file) is mapped to the z-th slice in certain order. However it seems that the instance number has nothing to do with the ordering according to the discussion here. – user1206899 Feb 14 '18 at 02:10
You are correct. The chest CT series are sorted from head to feet. The slice closest to the head should have the lowest Instance Number
.
I don't know if this is defined by the DICOM standard or not, but I have seen a lot of DICOM images and the convention is this:
- AXIAL - sorted by Z axis high to low (head to feet)
- CORONAL - sorted by Y axis high to low (back to front)
- SAGITTAL - sorted by X axis low to high (right to left)
Notice in all cases, the first slice in the series will be farthest from the observer.
If you need to generate Instance Number
, you should sort the images by the dot product of Image Position Patient
and (1,-1,-1)
from low to high. In the rare degenerate case (all dot products are the same), I don't know. Pick another direction to sort, but probably (0,-1,-1)
would be a good choice.
EDIT: I just discussed this with a friend who is more experienced. He said it varies. Some departments prefer back to front order, some prefer front to back. Also some DICOM viewers will give users the choice of how the slices are sorted (by Instance Number, Slice Location, IPP, Content Time, etc)

- 10,274
- 3
- 79
- 79