[Insight-users] ITK Image Coordinates / Problem withPhysicalPoint to Index Conversion

[Edson Tadeu]

Hi All,

On Jan 29, 2008 9:23 PM, Rupert Brooks <rupe.brooks at gmail.com> wrote:

> Hi Andreas,
>
> This is an important issue, particularly for anyone attempting to do
> subpixel accuracy registration.  I also agree that the coordinate of a
> pixel should be the center of that pixel.  This is because I tend to
> think of images as sampled signals - ie functions convolved with PSF
> and then a comb function - so they dont really have width as such.  If
> the coordinate is of the corner, for many reasons that you have
> pointed out, it could lead to strange contradictions or shifts in the
> effective image position.
>

I completely agree.. the "pixel" (or voxel) do not have even to be
rectangular... or the same size of the Spacing. They could be tiny
circles... or gaussians... or even tiny dots (dirac delta). E.g., in
visualization, when you consider the common linear interpolation, they have
a width of twice the Spacing (overlapping each other); considering bi-cubic
or other kinds of interpolation (Lanczos, etc.), they are even larger.

I vote for the center-based location approach (rounding mode), but an easy
way to switch to vertex-based should be available (maybe through a flag bit
and a shift in the Origin), because there may be some applications where
vertex-based information is more natural (finite elements, PDE, etc.).

As a note, there should always be an unambiguous (non-overlapping) pixel
domain [e.g., equivalent to the Voronoi diagram]. Even in the center-based
location, there are still an issue to be resolved: the domain of the
boundary pixels.

For example, for a 3x3 image, origin (0.0, 0.0), spacing (1.0, 1.0), the
domain of each pixel it would be something like this:

Pix [0,0]: [-Inf, -Inf] <= x < [0.5, 0.5]
Pix [1,0]: [-Inf, 0.5] <= x < [0.5, 1.5]
Pix [2,0]: [-Inf, 1.5] <= x < [0.5, Inf]
Pix [0,1]: [0.5, -Inf] <= x < [1.5, 0.5]
Pix [1,1]: [0.5, 0.5] <= x < [1.5, 1.5]
Pix [2,1]: [0.5, 1.5] <= x < [1.5, Inf]
Pix [0,2]: [1.5, -Inf] <= x < [Inf, 0.5]
Pix [1,2]: [1.5, 0.5] <= x < [Inf, 1.5]
Pix [2,2]: [1.5, 1.5] <= x < [Inf, Inf]

Note that there are three options to the domain of the boundary pixels:
1) Extend them to infinity (as I did)
2) Extend them so that they have the same "size" of the inner pixels. In
this case, the "image domain" would be (-0.5,-0.5) <= x < (2.5, 2.5)
3) Extend them to half (or 1/4) the size of the inner pixels, towards them.
In this case, the "image domain" would be (0.0, 0.0) <= x < (2.0, 2.0), but
the boundary pixels would be at the *vertices* of their domains.

Here is a fixed-width font diagram exemplifying it:

                |       |
                |       |
   (-0.5,2.5)   |       |   (2.5,2.5)
        +.......+.......+.......+
        .       |       |       .
        . [0,2].|.[1,2].|.[2,2] .
        .   .   |       |   .   .
   -----+-------+-------+-------+-----
        .   .   |       |   .   .
        . [0,1] | [1,1] | [2,1] .
        .   .   |       |   .   .
   -----+-------+-------+-------+-----
        .   .   |       |   .   .
        . [0,0].|.[1,0].|.[2,0] .
        .       |       |       .
        +.......+.......+.......+
   (-0.5,-0.5)  |       |   (2.5,-0.5)
                |       |
                |       |


Options 1 seems more natural to me, and it is explicit that this "image
domain" (Infinity) does not correspond to the real "image metrics" (0.0, 0.0)
to (3.0, 3.0).
Option 2 seems natural too, but note that *many* people will assume that the
"image domain" corresponds to the "image metrics", i.e., the image domain to
start at the Origin: (0.0, 0.0) to (3.0, 3.0) in this case. A solution would
be to shift the Origin by (-0.5, -0.5), but then, again, we would be moving
the information location from the center to the vertices ;).

Edson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20080130/2e55132f/attachment.htm