[Insight-users] bug in itkImageSpatialObject

Stefan Klein s.klein at erasmusmc.nl
Fri Aug 28 11:24:47 EDT 2009


Hi,
Update to previous email about itkImageSpatialObject:

There is still another bug in the itkImageSpatialObject, related to the 
bounding box. The bounding is not consistent with the 'centered-voxel' 
convention. I just realised that the bounding box of a 100x100 image 
probably should be [0,99]. (or [-0.5, 99.5], but for sure not [0,100]).

So, please find attached a new test program, including 
itkImageSpatialObject3, which fixes both the issue of my previous email 
and this issue.

The output of the test program:

ITK:
min: [0, 0]
max: [100, 100]
FIX:
min: [0, 0]
max: [100, 100]
FIXFIX:
min: [0, 0]
max: [99, 99]

ITK = ITK version
FIX = itkImageSpatialObject2 = the version of my previous email
FIXFIX = itkImageSpatialObject3
Obviously, I executed the test program with "factor=0", so identity 
direction cosines.

Maybe this fix should be part of the 
USE_CENTERED_COORDINATES_CONSISTENTLY cmake variable?

Kind regards,
Stefan

Stefan Klein wrote:
> Hi,
> 
> I believe I found a bug in the 
> ImageSpatialObject::ComputeLocalBoundingbox() method.
> 
> The bounding box is wrongly computed in case of rotated images. Attached 
> is a test program that produces the bug and tests a fix. A 100x100 image 
> is created, with a rotation matrix of 45 degrees (pi/4 rad) as direction 
> cosines. Below are the resulting bounding box min/max coordinates:
> 
> ITK:
> min: [0, 0]
> max: [70.7107, 70.7107]
> FIX:
> min: [-70.7107, 0]
> max: [70.7107, 141.421]
> 
> ITK = the itk implementation
> FIX = my proposed fix (itkImageSpatialObject2).
> 
> The bounding box of a rotated square of 100x100 can never become smaller 
> than 100x100, so the ITK result must be wrong.
> 
> By changing the variable 'factor' in the test program you will see that 
> with even values both versions give a correct result, but with odd 
> values the ITK version is faulty.
> 
> The cause of the failure lies in itkImageSpatialObject.txx lines 
> 256-260. By setting the minimum and maximum first, these point will 
> never be considered to be maximum or minimum, respectively.
> 
> Kind regards,
> Stefan.
> 
> 
> ------------------------------------------------------------------------
> 
> _____________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users


More information about the Insight-users mailing list