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

[Maarten Nieber]

Hi Andreas,

with respect to the "co-ordinate representation of a voxel", I'm not completely sure what you mean, but I think that for the conversion between index and physical point, the following functions are needed:

- given a physical point, there should be a function that returns the index of the pixel that contains this physical point.

- given a pixel index, there should be a function that returns the physical point at the center of this pixel.

In my opinion, for an 2x2 image with spacing: 1mm and origin: 0mm/0mm, the function PhysicalPointToIndex( 0.6, 0.6 ) should return the index (0,0). The function IndexToPhysicalPointAtPixelCenter( 0, 0 ) should return the point (0.5, 0.5). The extent of the image should be (0,0) - (2,2). (Of course, the function arguments should be itkPoint, I simplified the notation). Again, this is just my preference.

Best regards
Maarten



----- Original Message ----
From: Andreas Keil <andreas.keil at cs.tum.edu>
To: insight-users at itk.org
Cc: Maarten Nieber <hallomaarten at yahoo.com>
Sent: Tuesday, December 18, 2007 1:30:21 PM
Subject: RE: [Insight-users] ITK Image Coordinates / Problem with Physical Point to Index Conversion


Hi Maarten,

thank you for your reply (which other list subscribers may find below).
 My
initial posting was biased towards changing the ITK implementation
 rather
than the documentation for the following reasons:

Working with the physical coordinates of a voxel usually means that one
needs a single coordinate representation of a voxel. Algorithms relying
one this single physical coordinate would usually prefer the center of
 a
voxel for their space-related computations.

Moreover, ITK images only reflect the spacing between voxels which is
 not
necessarily equal to the width of a voxel. I am pretty sure that there
 are
cases where the voxel width is smaller than the spacing (in CT for
example). In this case, the term "spacing" would also be ambigious if
 it
would not refer to the distance between adjacent voxels' centers.

What do others think about this? I would appreciate a clearification as
the definitions of image origin and spacing really matter for my
application in 3D reconstruction. 

Thank you,
Andreas.



-----Original Message-----
From: Maarten Nieber [mailto:hallomaarten at yahoo.com] 
Sent: Tuesday, December 18, 2007 10:11
To: Andreas Keil
Subject: Re: [Insight-users] ITK Image Coordinates / Problem with
 Physical
Point to Index Conversion

Hi Andreas,

I agree with you that according to the software guide, mapping (0.6,
 0.6)
should yield an index of (0,0).
On the other hand, I think that the definition of origin in the
 software
guide is not intuitive.
It says "the image origin is associated with the co-ordinates of the
 first
pixel in the image". Probably, it would be more accurate to say that
 the
image origin is associated with the >center< of the first pixel in the
image. However, by using this definition, the extent of an image with
origin (0,0) contains negative co-ordinates. I would find it more
intuitive if the extent of such an image is something like (0,0) -
 (size1,
size2). This would be the case if the origin of the image is associated
with the bottom-left corner of the first pixel.

If in the itk code, the origin of an itk image co-incides with the
 bottom
left corner of the first pixel, then I would prefer to change the
 software
guide and not the code.

Best regards
Maarten Nieber



----- Original Message ----
From: Andreas Keil <andreas.keil at cs.tum.edu>
To: insight-users at itk.org
Sent: Friday, December 14, 2007 6:10:25 PM
Subject: [Insight-users] ITK Image Coordinates / Problem with Physical
Point to Index Conversion

Hi,

I think I have discovered an inconsistency between the ITK Software
 Guide
(p.40) and the implementation of itk::Image (all the methods taking
physical points / continuous indices as arguments):

The trunctation of continuous index coordinates to integers does not
 yield
the correct pixel coordinates as expected by looking at the definition
 in
the software guide.

A simple example is:
Image spacing: 1mm
Image origin: 0mm/0mm

The pixel with index (1/1) would (according to the software guide) have
the following extents:
0.5mm/0.5mm to 1.5mm/1.5mm

However, the physical point 0.6mm/0.6mm gets mapped to the index 0/0 by
the method TransformPhysicalPointToIndex.

The solution would be to check those conversion methods as well as
 others
(like IsInside) and replace integer truncations with rounding.

If my reasoning is correct, I'll file a bug report. However, I'd like
 to
have some confirmation first.

Thanks,
Andreas.







      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20071219/07107bfc/attachment.html