[Dcmlib] HOWTO Compute the Z spacing in DICOM

[Mathieu Malaterre]

http://groups.google.com/group/comp.protocols.dicom/msg/5016d604cbc9e828?dmode=source&hl=en


I agree that (0018,0088) Spacing Between Slices, used in the MR & NM
images (but not in CT images, unless one is extending the SOP
Class) is the distance between the centers of the slices (and
most definitely not between the edges of the slices, i.e. it is
not the gap as some buggy implementations have sent in the past).

However I do not agree that (0018,0050) Slice Thickness, which
occurs in the image plane module and is used in both CT and MR,
is necessarily related to collimation. It is defined only as
"nominal slice thickness".

In the case of helical CT for example, the reconstructed slice
thickness is not necessarily directly related to the collimation
of the X-ray beam. Same applies to multi-planar reconstructions.
It is clearly more appropriate to send the reconstructed thickness
of the slice in these cases than the collimator aperture. They may
be the same, but not always.

The same attribute used in MR also obviously needs to be the
reconstructed thickness, since there is no other thickness to
send.

Finally, depending on (0018,0088) Spacing Between Slices is not
a good idea, since it isn't sent for CT normally, and it isn't
always right in MR images, and it is always wrong when one is
changing spacing on the fly, e.g. going from 10 to 5mm spacing
and back again, what spacing to use for the boundary slices ?

It is always better to compute the distance between a pair of
slices along a normal to the plane of the image specified by
the Image Orientation (Patient) attribute, by projecting the
top left hand corner position specified by the Image Position
(Patient) attribute onto that normal. These attributes are
always sent and much more often "right" than is (0018,0088).

Also, never use Slice Location (0020,1041) for this purpose ...
it is purely descriptive and often empty, wrong or useless
for anything other than trying to reproduce a manufacturer's
native annotation on the display or film.

What you describe sounds like doing an MPR, in which case you
should recompute the two parameters based on whatever the
thickness and spacing of your reconstructions are, and not
just reuse the original parameters.

david