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

[Edson Tadeu]

On Jan 9, 2008 4:38 AM, Steve M. Robbins <steve at sumost.ca> wrote:

> Hello Andreas,
>
> I think you're right: the docs are correct but the code is buggy.
>
>
> On Tue, Jan 08, 2008 at 10:37:32AM +0100, Andreas Keil wrote:
>
> > As mentioned in my earlier post (see below), the documentation and
> > (...)
>
> Right.  I find the centre-based coordinate convention to be much more
> natural; e.g. when writing out formulas for interpolation.  If you're
> taking votes, put me down for the centre.
>
> I think the centre-based coordinate convention is more common with
> image processing folk, whereas the corner-based convention is more
> common in graphics circles.  For what it's worth, VTK's image data is
> said to use the centre-based coordinate system [1].  On the other
> hand, VTK uses corner convention for screen pixel coordinates, and I
> suspect this confusion underlies the problems in VTK's coordinate
> conversion routines [2].
>
>

Hi,

 Independent of using center-based or corner-based data location, the actual
implementation of PhysicalPoint To Index uses TRUNCATION as a rounding mode,
and this is plain wrong (it is implementing neither of the solutions). If
you allow a negative Origin (e.g., (-0.4, -0.4)), then you could have one
pixel with coordinate at -0.4 mapped to 0.0, and then the next pixel with
coordinate at 0.6 mapped to 0.0 again. I suggest using Floor (corner-based
approach) or proper Rounding (center-based approach).

 Whatever solution is chosen, I think it should also be reflected in
itk::OrientedImage. Whatever solution is chosen, the data location can be
changed from center to corner and vice versa through a shift of the Origin
(by Spacing/2 for itk::Image or by Direction*Spacing*(0.5,0.5,0.5) for
itk::OrientedImage); because of this, I would suggest to take the approach
that breaks less code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20080109/81a16b20/attachment.html