<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hi Andreas,<br><br>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:<br><br>- given a physical point, there should be a function that returns the index of the pixel that contains this physical point.<br><br>- given a pixel index, there should be a function that returns the physical point at the center of this pixel.<br><br>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.<br><br>Best regards<br>Maarten<br><br><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Andreas Keil <andreas.keil@cs.tum.edu><br>To: insight-users@itk.org<br>Cc: Maarten Nieber <hallomaarten@yahoo.com><br>Sent: Tuesday, December 18, 2007 1:30:21 PM<br>Subject: RE: [Insight-users] ITK Image Coordinates / Problem with Physical Point to Index Conversion<br><br>
Hi Maarten,<br><br>thank you for your reply (which other list subscribers may find below).
My<br>initial posting was biased towards changing the ITK implementation
rather<br>than the documentation for the following reasons:<br><br>Working with the physical coordinates of a voxel usually means that one<br>needs a single coordinate representation of a voxel. Algorithms relying<br>one this single physical coordinate would usually prefer the center of
a<br>voxel for their space-related computations.<br><br>Moreover, ITK images only reflect the spacing between voxels which is
not<br>necessarily equal to the width of a voxel. I am pretty sure that there
are<br>cases where the voxel width is smaller than the spacing (in CT for<br>example). In this case, the term "spacing" would also be ambigious if
it<br>would not refer to the distance between adjacent voxels' centers.<br><br>What do others think about this? I would appreciate a clearification as<br>the definitions of image origin and spacing really matter for my<br>application in 3D reconstruction. <br><br>Thank you,<br>Andreas.<br><br><br><br>-----Original Message-----<br>From: Maarten Nieber [mailto:<a ymailto="mailto:hallomaarten@yahoo.com" href="mailto:hallomaarten@yahoo.com">hallomaarten@yahoo.com</a>] <br>Sent: Tuesday, December 18, 2007 10:11<br>To: Andreas Keil<br>Subject: Re: [Insight-users] ITK Image Coordinates / Problem with
Physical<br>Point to Index Conversion<br><br>Hi Andreas,<br><br>I agree with you that according to the software guide, mapping (0.6,
0.6)<br>should yield an index of (0,0).<br>On the other hand, I think that the definition of origin in the
software<br>guide is not intuitive.<br>It says "the image origin is associated with the co-ordinates of the
first<br>pixel in the image". Probably, it would be more accurate to say that
the<br>image origin is associated with the >center< of the first pixel in the<br>image. However, by using this definition, the extent of an image with<br>origin (0,0) contains negative co-ordinates. I would find it more<br>intuitive if the extent of such an image is something like (0,0) -
(size1,<br>size2). This would be the case if the origin of the image is associated<br>with the bottom-left corner of the first pixel.<br><br>If in the itk code, the origin of an itk image co-incides with the
bottom<br>left corner of the first pixel, then I would prefer to change the
software<br>guide and not the code.<br><br>Best regards<br>Maarten Nieber<br><br><br><br>----- Original Message ----<br>From: Andreas Keil <<a ymailto="mailto:andreas.keil@cs.tum.edu" href="mailto:andreas.keil@cs.tum.edu">andreas.keil@cs.tum.edu</a>><br>To: <a ymailto="mailto:insight-users@itk.org" href="mailto:insight-users@itk.org">insight-users@itk.org</a><br>Sent: Friday, December 14, 2007 6:10:25 PM<br>Subject: [Insight-users] ITK Image Coordinates / Problem with Physical<br>Point to Index Conversion<br><br>Hi,<br><br>I think I have discovered an inconsistency between the ITK Software
Guide<br>(p.40) and the implementation of itk::Image (all the methods taking<br>physical points / continuous indices as arguments):<br><br>The trunctation of continuous index coordinates to integers does not
yield<br>the correct pixel coordinates as expected by looking at the definition
in<br>the software guide.<br><br>A simple example is:<br>Image spacing: 1mm<br>Image origin: 0mm/0mm<br><br>The pixel with index (1/1) would (according to the software guide) have<br>the following extents:<br>0.5mm/0.5mm to 1.5mm/1.5mm<br><br>However, the physical point 0.6mm/0.6mm gets mapped to the index 0/0 by<br>the method TransformPhysicalPointToIndex.<br><br>The solution would be to check those conversion methods as well as
others<br>(like IsInside) and replace integer truncations with rounding.<br><br>If my reasoning is correct, I'll file a bug report. However, I'd like
to<br>have some confirmation first.<br><br>Thanks,<br>Andreas.<br><br></div><br></div></div><br>
<hr size=1>Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. <a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ "> Try it now.</a></body></html>