On Jan 9, 2008 4:38 AM, Steve M. Robbins <<a href="mailto:steve@sumost.ca">steve@sumost.ca</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Andreas,<br><br>I think you're right: the docs are correct but the code is buggy.<br><div class="Ih2E3d"><br><br>On Tue, Jan 08, 2008 at 10:37:32AM +0100, Andreas Keil wrote:<br><br>> As mentioned in my earlier post (see below), the documentation and
<br>> (...)<br><br></div>Right. I find the centre-based coordinate convention to be much more<br>natural; e.g. when writing out formulas for interpolation. If you're<br>taking votes, put me down for the centre.<br>
<br>I think the centre-based coordinate convention is more common with<br>image processing folk, whereas the corner-based convention is more<br>common in graphics circles. For what it's worth, VTK's image data is
<br>said to use the centre-based coordinate system [1]. On the other<br>hand, VTK uses corner convention for screen pixel coordinates, and I<br>suspect this confusion underlies the problems in VTK's coordinate<br>conversion routines [2].
<br><br></blockquote></div><br><br>Hi,<br>
<br>
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).<br>
<br>
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.<br>
<br><br>