[Insight-users] Funny LabelObject GetCentroid() behaviour

Tue Sep 21 05:18:56 EDT 2010

Hello Gaetan,

thanks for answering my mail!

Actually I wasn't aware of the overflow bug so I tried the patch but
the results were the same. As far as I got the shapelabel code first
computes the centroid in pixels and then converts it to physical units
with a call to:

290 output->TransformContinuousIndexToPhysicalPoint( centroid,
physicalCentroid );

The indexes in the "centroid" variable are correct, that's what is in
"physicalCentroid" that is negative.

This is why I started thinking that the problem might be in how the
different gdcm versions computes origin and spacing:

http://sourceforge.net/mailarchive/message.php?msg_name=AANLkTikjmhTA-7KQbRpZWqkB9uHPdHOZ_r5r0eiPrA9x%40mail.gmail.com

But still I haven't received a confirmation from the gdcm list.

By the way, it is here (
http://mima2.jouy.inra.fr/git/contrib-itk/binaryAttributeMorphology/ )
that the most up-to-date attribute morphology code resides?

Thanks and regards,

Mario

2010/9/20 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> Hi Mario,
>
> Thanks to have let us know your progress on that problem.
> I've checked two weeks of emails today, and I've first thought it might be
> related to that bug, corrected a few months ago:
>
>  [glehmann at gbook ITK]$ git show fe342353284f4e9b970e548efadb8e12a74f6207
>  commit fe342353284f4e9b970e548efadb8e12a74f6207
>  Author: Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>
>  Date:   Fri Jun 4 09:00:41 2010 -0400
>
>      BUG: Fix overflow with negative indexes
>
>  diff --git a/Code/Review/itkShapeLabelMapFilter.txx
> b/Code/Review/itkShapeLabelMapFilter.txx
>  index 6151e58..5ed8251 100644
>  --- a/Code/Review/itkShapeLabelMapFilter.txx
>  +++ b/Code/Review/itkShapeLabelMapFilter.txx
>  @@ -129,10 +129,10 @@ ShapeLabelMapFilter<TImage, TLabelImage>
>       // First, update the axes that are not 0
>       for( int i=1; i<ImageDimension; i++ )
>         {
>  -      centroid[i] += length * idx[i];
>  +      centroid[i] += (long)length * idx[i];
>         }
>       // Then, update the axis 0
>  -    centroid[0] += idx[0] * length + ( length * ( length - 1 ) ) / 2.0;
>  +    centroid[0] += idx[0] * (long)length + ( length * ( length - 1 ) ) /
> 2.0;
>
>       // Update the mins and maxs
>       for( int i=0; i<ImageDimension; i++)
>
> Regards,
>
> Gaëtan
>
>
> Le 17 sept. 10 à 17:05, Mario Ceresa a écrit :
>
>> Hello again!
>> At last I traced the problem down to GDCM itself.
>>
>> In one machine I compiled ITK using the included gdcm lib (ver 1.2.2?)
>> while in the other I link against the newer gdcm 2.0.
>>
>> It seems that the gdcm 2.0 that I installed is not reading correctly
>> the origin and the spacing from the dicom header, as the values
>> defaults to (0,0,0) and (1,1,1).
>>
>> On the other machine gdcm 1.22 reads the values (-211, -430, -347.5)
>> and (0.8, 0.8, 1) and this originates the negative centroid after a
>> call to:
>> output->TransformContinuousIndexToPhysicalPoint( centroid,
>> physicalCentroid );
>>
>> I'll separately ask to the gdcm mailing list for help!
>>
>> Thanks and sorry for the noise,
>>
>> Mario
>>
>> On 14 September 2010 18:33, Mario Ceresa <mrceresa at gmail.com> wrote:
>>>
>>> Hello everybody!
>>> I have a funny problem with the GetCentroid() method of LabelObject:
>>>
>>> On a Fedora 13 64 bit - ITK 3.16 +  binaryAttributeMorphology
>>> downloaded on Jan  3  2010 everything works correctly:
>>>
>>> [mario at 1006505 bin]$ ./test_centroid 3-map.dcm
>>>   Considering object 1 with size 37839488 and center [251.218,
>>> 171.493, 174.806]
>>>   Considering object 2 with size 9791707 and center [261.554,
>>> 316.538, 154.827]
>>>   Considering object 20 with size 134676 and center [373.458,
>>> 177.895, 337.078]
>>>
>>> On a Red Hat Enterprise Linux Server release 5.5 - 64 bit - with the
>>> same ITK and binaryAttributeMorphology version, the output is:
>>>
>>> [mario at 1006504 bin]$ test_centroid 3-map.dcm
>>>   Considering object 1 with size 37839488 and center [-9.43763,
>>> -292.436, -172.694]
>>>   Considering object 2 with size 9791707 and center [-1.14033,
>>> -176.002, -192.673]
>>>   Considering object 20 with size 134676 and center [88.689,
>>> -287.296, -10.4225]
>>>
>>> I attach the program that I used to test the error and I also uploaded
>>> the image on dropbox just in case:
>>>
>>> http://dl.dropbox.com/u/9513411/3-map.dcm.tar.gz
>>>
>>> Thanks for any insight ;) you might provide on this issue,
>>>
>>> With best regards,
>>>
>>> Mario
>>>
>> _____________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://www.kitware.com/products/protraining.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
>
> --
> Gaëtan Lehmann
> Biologie du Développement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr  http://www.itk.org
> http://www.mandriva.org  http://www.bepo.fr
>
>