<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;"><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><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, January 08, 2008 12:54<br>To: Andreas Keil<br>Subject: Re: [Insight-users] ITK Image Coordinates / Problem with<br>PhysicalPoint to Index Conversion<br><br>Hi Andreas,<br><br>I agree with you that this issue is of very high importance!<br><br>-- quote from your previous post --<br>I think that the personal preference<br>for one of the two options we have basically depends on whether one is<br>more interested in the overall dimensions of a
dataset or whether one
has<br>to do voxel-wise operations depending on the physical coordinate.<br>-- end quote --<br><br>Can you explain why you think - for doing voxel-wise operations - it would be better if the image origin co-incides with the center of a pixel?<br><br>Best regards,<br>Maarten<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: Tuesday, January 8, 2008 10:37:32 AM<br>Subject: RE: [Insight-users] ITK Image Coordinates / Problem with<br>PhysicalPoint to Index Conversion<br><br>Dear all,<br><br>I would like to try a restart of the discussion related to the
definition<br>of physical coordinates if ITK images:<br><br>As mentioned in my earlier post (see below), the documentation and<br>implementation differ in this point. The two proposed solutions are
either<br>fixing the documentation (ITK Software Guide, p. 40) and defining the<br>origin to lie in the "lower-left(-back)" corner of the pixel with index<br>0/0(/0) or fixing the implementation of the respective methods<br>(IndexToPhysicalPoint, PhysicalPointToIndex, etc.) and defining the
origin<br>to lie in the center of this pixel.<br><br>So far, only Maarten and I were discussing about this, with him
favoring<br>to fix the docs and me favoring to fix the implementation. Another<br>argument I found for my preference is that the origin would not have to<br>change when downsampling an image. I think that the personal preference<br>for one of the two options we have basically depends on whether one is<br>more interested in the overall dimensions of a dataset or whether one
has<br>to do voxel-wise operations depending on the physical coordinate.<br><br>--> Therefore, I strongly ask other ITK users and developers to take
part<br>in this discussion so that we can make a decision. This problem is
really<br>of high importance since it is related to the core of the lib (namely
the<br>ImageBase class) and it has a big influence on reconstruction problems.
As<br>soon as we have come to a conclusion, I would file a bug report with
the<br>proposed solution.<br><br>Thank you,<br>Andreas.<br><br><br><br>-----Original Message-----<br>From: insight-users-bounces+andreas.keil=<a ymailto="mailto:cs.tum.edu@itk.org" href="mailto:cs.tum.edu@itk.org">cs.tum.edu@itk.org</a><br>[mailto:insight-users-bounces+andreas.keil=<a ymailto="mailto:cs.tum.edu@itk.org" href="mailto:cs.tum.edu@itk.org">cs.tum.edu@itk.org</a>] On
Behalf<br>Of Andreas Keil<br>Sent: Tuesday, December 18, 2007 13:30<br>To: <a ymailto="mailto:insight-users@itk.org" href="mailto:insight-users@itk.org">insight-users@itk.org</a><br>Subject: RE: [Insight-users] ITK Image Coordinates / Problem with<br>PhysicalPoint 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>_______________________________________________<br>Insight-users mailing list<br><a ymailto="mailto:Insight-users@itk.org" href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br><a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br><br><br><br>________________________________<br><br>Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
it<br>now.<br><<a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62s" target="_blank">http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62s</a><br>R8HDtDypao8Wcj9tAcJ> <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>