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 ...

+ Reply to Thread
Results 1 to 8 of 8

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?

    Thanks in advance,

    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?

    Thanks for your elaborate answer.

    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
    meaning of slice thickness but I'll create a separate thread about
    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?


    Exactly! Glad you caught that!

    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
    easily answered questions of geometry. Implementing the answers
    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
    > easily answered questions of geometry. *Implementing the answers
    > 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

+ Reply to Thread