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

Tue Jan 29 09:12:27 EST 2008

Hello Maarten and Andreas, and it-users
I would vote to better change the documentation than the code. I don't 
know for sure, but I suppose there are some fitlers that already assume 
the origin to be set in the lower-left-back (llb) corner in the image.
Eliana

--> white noise? <--

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

-- 
Eliana M. Vásquez Osorio
PhD Student (OIO)
Erasmus Medical Center - Daniel den Hoed Cancer Center
Department of Radiation Oncology
Groene Hilledijk 301 
3075 EA Rotterdam
The Netherlands

T: +31 10 – 43 91 491 
F: +31 10 – 43 91 012
E-mail: e.vasquezosorio at erasmusmc.nl