# Is a voxel a little cuboid? - DICOM

This is a discussion on Is a voxel a little cuboid? - DICOM ; Hi, Awhile ago I read a paper by Alvy Ray Smith called "A Pixel Is Not A Little Square...". You can find it here: http://alvyray.com/Memos/MemosMicros...xelIsNotSquare . This paper made me wonder how I should look at a voxel in for ...

# Thread: Is a voxel a little cuboid?

1. ## Is a voxel a little cuboid?

Hi,

Awhile ago I read a paper by Alvy Ray Smith called "A Pixel Is Not A
Little Square...". You can find it here:
http://alvyray.com/Memos/MemosMicros...xelIsNotSquare. This
paper made me wonder how I should look at a voxel in for example a
DICOM CT image. Is it a sample at a certain point or is it a little
cuboid?

The viewpoint that a voxel is a little cuboid can be united with the
viewpoint that a voxel is a point sample: apply a box filter before
sampling the continuous volume. That way the voxels are point samples
of the filtered volume and the value of each voxel is the average
value of a cuboid in the original continuous volume.

I understand that to avoid aliasing you need to apply a low-pass
filter that filters out frequencies above the Nyquist frequency before
sampling the continuous volume and that a box filter is a really poor
low-pass filter. This makes me think that voxels are point samples and
that maybe a box-like filter is used in practice but that in the ideal
case a sinc filter would be used.

The Slice Thickness (0018,0050) attribute on the other hand indicates
that a voxel has a certain thickness. This seems to suggest that
voxels are little cuboids because cuboids have a thickness and points
don't.

So which of the two viewpoints is the correct one in the case of DICOM
images?

Remco Harmsen

2. ## Re: Is a voxel a little cuboid?

The idea of "pixel size" can cause all sorts of headaches!

The measurement process is highly dependent on the modality and
on acquisition parameters, but for display purposes, I treat
pixels as measurements at points in space. In fact, a basic
definition of an image is a mapping of some property of an object
from object space into image space. That mapping is not one to
one, but usually mixes data about the object property from some
(reasonably small) volume into each image point.

DICOM defines coordinate systems for handling mapping of the
image data back to space in C.7.6.2. I can tell you how I use
those coordinate systems to display images.

In order to display an image (any image, not just those
transfered with DICOM), appropriate values need to be assigned to
each display pixel. C.7.6.2 defines a mapping from pixel data
array indices to space using the pixel spacings, image position,
orientation and pixel data dimensions. Let's call that mapping

P = M_p J_p,

where P_p is a homogeneous point in space, J_p is a homogeneous
point in pixel data index space, and Mp is the mapping as per
C.7.6.2. Note that if we had a perfect imaging system, with a
perfect point spread function and no sampling limitations on the
transfer functions, the M_p would be the inverse of the original
mapping applied in creating the image.

For the sake of consistency, I've adopted a nearly identical
definition for all our image data, DICOM or not. The difference
is that I tend to prefer to do this all in 3D array index space,
rather than the 3D that C.7.6.2 uses. Then I define a similar
mapping from space to the display pixel indices:

P = M_d J_d.

These can easily be combined to map display indices to pixel data
indices:

J_p = M_d^{-1} P = M_d^{-1} M_d J_d

where M_d^{-1} is the inverse of M_d. J_p is not typically going
to map exactly to one of the image pixel data points, so to
determine the pixel data value, some interpolation is needed.
Aliasing can be handled at that interpolation step, or by
filtering the display image before display.

You'll notice that all of this manipulation treats the pixel data
as measurements at points in index space. The mappings depend
only on pixel and slice spacing, there is no need to introduce
the concept of pixel size. Things like slice thickness are then
representative of the imaging process and are distinct from slice
spacing.

Mike

P.S. The basic reference that I use for this is 3D graphics part
of "Fundamentals of Interactive Computer Graphics," Foley and Van
Dam, Addison-Wesley 1982. There is also a fairly complete
notation in Phys Med Biol 46 (2001) R1-R45, "Medical Image
Registration".

3. ## Re: Is a voxel a little cuboid?

On 22 jan, 00:46, mmill...@iupui.edu (Michael A. Miller) wrote:
> The idea of "pixel size" can cause all sorts of headaches!
>

I noticed :-)

[snip]

> These can easily be combined to map display indices to pixel data
> indices:
>
> * J_p = M_d^{-1} P = M_d^{-1} M_d J_d
>
> where M_d^{-1} is the inverse of M_d.

I assume you mean:

J_p = M_p^{-1} P = M_p^{-1} M_d J_d

where M_p^{-1} is the inverse of M_p?

[snip]

> You'll notice that all of this manipulation treats the pixel data
> as measurements at points in index space. *The mappings depend
> only on pixel and slice spacing, there is no need to introduce
> the concept of pixel size. *Things like slice thickness are then
> representative of the imaging process and are distinct from slice
> spacing.
>

I hadn't looked at it like that. This makes me wonder about the
that.

Remco

4. ## Re: Is a voxel a little cuboid?

>>>>> "remcoh" == remcoh writes:

> I assume you mean:

> J_p = M_p^{-1} P = M_p^{-1} M_d J_d

> where M_p^{-1} is the inverse of M_p?

Mike

5. ## Re: Is a voxel a little cuboid?

Hum...

For display, treating the data as point samples is O.K. but when you
want to segment the data, or compute anatomical volumes, don't you
need to consider the data as volumes?

Yves

On Mon, 21 Jan 2008 18:46:24 -0500, mmiller3@iupui.edu (Michael A.
Miller) wrote:

>The idea of "pixel size" can cause all sorts of headaches!
>
>The measurement process is highly dependent on the modality and
>on acquisition parameters, but for display purposes, I treat
>pixels as measurements at points in space. In fact, a basic
>definition of an image is a mapping of some property of an object
>from object space into image space. That mapping is not one to
>one, but usually mixes data about the object property from some
>(reasonably small) volume into each image point.
>
>DICOM defines coordinate systems for handling mapping of the
>image data back to space in C.7.6.2. I can tell you how I use
>those coordinate systems to display images.
>
>In order to display an image (any image, not just those
>transfered with DICOM), appropriate values need to be assigned to
>each display pixel. C.7.6.2 defines a mapping from pixel data
>array indices to space using the pixel spacings, image position,
>orientation and pixel data dimensions. Let's call that mapping
>
> P = M_p J_p,
>
>where P_p is a homogeneous point in space, J_p is a homogeneous
>point in pixel data index space, and Mp is the mapping as per
>C.7.6.2. Note that if we had a perfect imaging system, with a
>perfect point spread function and no sampling limitations on the
>transfer functions, the M_p would be the inverse of the original
>mapping applied in creating the image.
>
>For the sake of consistency, I've adopted a nearly identical
>definition for all our image data, DICOM or not. The difference
>is that I tend to prefer to do this all in 3D array index space,
>rather than the 3D that C.7.6.2 uses. Then I define a similar
>mapping from space to the display pixel indices:
>
> P = M_d J_d.
>
>These can easily be combined to map display indices to pixel data
>indices:
>
> J_p = M_d^{-1} P = M_d^{-1} M_d J_d
>
>where M_d^{-1} is the inverse of M_d. J_p is not typically going
>to map exactly to one of the image pixel data points, so to
>determine the pixel data value, some interpolation is needed.
>Aliasing can be handled at that interpolation step, or by
>filtering the display image before display.
>
>You'll notice that all of this manipulation treats the pixel data
>as measurements at points in index space. The mappings depend
>only on pixel and slice spacing, there is no need to introduce
>the concept of pixel size. Things like slice thickness are then
>representative of the imaging process and are distinct from slice
>spacing.
>
>Mike
>
>P.S. The basic reference that I use for this is 3D graphics part
>of "Fundamentals of Interactive Computer Graphics," Foley and Van
>Dam, Addison-Wesley 1982. There is also a fairly complete
>notation in Phys Med Biol 46 (2001) R1-R45, "Medical Image
>Registration".

6. ## Re: Is a voxel a little cuboid?

>>>>> "Yves" == Yves Martel writes:

> Hum... For display, treating the data as point samples is
> O.K. but when you want to segment the data, or compute
> anatomical volumes, don't you need to consider the data as
> volumes?

Good point - the answer depends on how you calculate volumes.

If the surface defining the volume is defined by, well, some
surface, then it doesn't need to have anything at all to do with
a collection of little cubes.

If you consider the data as a collection of voxels that define
cuboids and the volume you're interested in is bounded by a
surface made up from some of those cuboids, then that works too.

As a scientist, I tend to think of imaging data as data. Many
clinical medical imaging systems have evolved from handling
images as pictures, which are a different beast. My point is
that image /data/ is collected at discrete points, or at least
represented that way after reconstruction. The data is displayed
on display devices that have pixels (and maybe voxels). Mixing
the two concepts, data and display of data, can lead to some
unnecessary complications.

For instance, we store data in a PACS, which is designed for
storing (P)pictures, not data, so naturally we tend to think of
the content in terms of pictures and display. When we start to
consider data that doesn't naturally fit into the picture model
(where picture = 2D collection of rectangular pixels), we extend
the idea of pixel to voxel and we get into the sort of discussion
we're having here. If instead we treat the data as points and
handle the geometry carefully, these questions are replaced by
with real world systems is not always easy, because we've got
mixed layers of abstraction combining all our ideas about
displaying and storing pictures and displaying and storing data.
It is especially hard if we're not aware of that mixture.

Mike

--
Michael A. Miller mmiller3@iupui.edu
Imaging Sciences, Department of Radiology, IU School of Medicine

7. ## Re: Is a voxel a little cuboid?

On 23 jan, 16:52, mmill...@iupui.edu (Michael A. Miller) wrote:

[snip]

> As a scientist, I tend to think of imaging data as data. *Many
> clinical medical imaging systems have evolved from handling
> images as pictures, which are a different beast. *My point is
> that image /data/ is collected at discrete points, or at least
> represented that way after reconstruction. *The data is displayed
> on display devices that have pixels (and maybe voxels). *Mixing
> the two concepts, data and display of data, can lead to some
> unnecessary complications.
>
> For instance, we store data in a PACS, which is designed for
> storing (P)pictures, not data, so naturally we tend to think of
> the content in terms of pictures and display. *When we start to
> consider data that doesn't naturally fit into the picture model
> (where picture = 2D collection of rectangular pixels), we extend
> the idea of pixel to voxel and we get into the sort of discussion
> we're having here. *If instead we treat the data as points and
> handle the geometry carefully, these questions are replaced by
> with real world systems is not always easy, because we've got
> mixed layers of abstraction combining all our ideas about
> displaying and storing pictures and displaying and storing data.
> It is especially hard if we're not aware of that mixture.
>

Am I right If I say that you see the display of image data as
something more abstract, e.g. more like generating a chart? I can see
that you can display image data this way independent of the kind of
measurement performed at each pixel or voxel. A person that is viewing
the displayed image data can determine the kind of measurements
performed from DICOM attributes like Modality, Slice Thickness etc,
just like a person viewing a chart can determine this from for example
the legend.

I'm wondering whether a thick slab MPR, where a slice thickness is
specified by the user, can also be created independent of the kind of
measurement performed at each voxel. I have a feeling that the slice
thickness of the original images should be included in the calculation
of a thick slab MPR.

Remco Harmsen

8. ## Re: Is a voxel a little cuboid?

>>>>> "remcoh" == remcoh writes:

> Am I right If I say that you see the display of image data
> as something more abstract, e.g. more like generating a
> chart?

Yes - that is how I try to view it.

> I'm wondering whether a thick slab MPR, where a slice
> thickness is specified by the user, can also be created
> independent of the kind of measurement performed at each
> voxel. I have a feeling that the slice thickness of the
> original images should be included in the calculation of a
> thick slab MPR.

I suppose it all depends on how you do the projection and what
the goal of the process is. I consider the generation of the MPR
as a processing step that creates a new piece of data, which can
then be displayed as an image, just like any other image. The
meaning of the data that is being displayed is certainly
dependent on the original acquisition method and on how
post-processing steps, such as MPR, where carried out.

Mike