[Insight-users] crashes N-D Linear Time Exact Signed Euclidean Distance Transform

[Oleksandr Dzyubak]

Hi Bill,

It becomes even more interesting.

I have rebuilt both ITK and a code.
Now, as you predicted, the filter works fine on both
SquareBinary201.hdr and SquareBinary201.png.

After all my tests, now complains from AnalyzeImageIO at all. That is a 
good part.

The bad part is that the 3D version of the filter now does not work.
At this point I am getting a bit different error message though (see below).

********* Begin Valgrind Error Log ******

dzyubak at debian: /BUILD$ valgrind 
./SignedMaurerDistanceMapImageFilterTest SquareBinary201.hdr test.hdr
==8807== Memcheck, a memory error detector.
==8807== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==8807== Using LibVEX rev 1658, a library for dynamic binary translation.
==8807== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==8807== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==8807== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==8807== For more details, rerun with: -v
==8807==
SignedMaurerDistanceMapImageFilterTest: 
/usr/local/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_vector.h:168: 
T& vnl_vector<T>::operator()(unsigned int) [with T = double]: Assertion 
`i<size()' failed.
==8807==
==8807== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 69 from 1)
==8807== malloc/free: in use at exit: 928,723 bytes in 14,072 blocks.
==8807== malloc/free: 17,555 allocs, 3,483 frees, 3,064,098 bytes allocated.
==8807== For counts of detected errors, rerun with: -v
==8807== searching for pointers to 14,072 not-freed blocks.
==8807== checked 1,697,288 bytes.
==8807==
==8807== LEAK SUMMARY:
==8807==    definitely lost: 0 bytes in 0 blocks.
==8807==      possibly lost: 244,008 bytes in 10,849 blocks.
==8807==    still reachable: 684,715 bytes in 3,223 blocks.
==8807==         suppressed: 0 bytes in 0 blocks.
==8807== Reachable blocks (those to which a pointer was found) are not 
shown.
==8807== To see them, rerun with: --show-reachable=yes
Aborted
********* End Valgrind Error Log ******

Bill Lorensen wrote:
> You are correct, it should work for 2d. It is (was) a bug in the
> itkAnalyzeImageIO class. The bug was both for reading and writing.
> This was fixed today. You can get the fixed files from the cvs
> repository.
>
> cd Insight/Code/IO
> cvs update itkAnalyzeImageIO.h itkAnalyzeImageIO.cxx
>
> Then rebuild ITK and your code.
>
> Bill
>
>
> On Mon, Jun 2, 2008 at 3:18 PM, Oleksandr Dzyubak <adzyubak at gmail.com> wrote:
>   
>> Hi Bill,
>>
>> Now I am a bit confused by what you are saying.
>>
>> 1) You say that it works for 3D but does not for 2D.
>> I cannot understand that since 2D dimensionality is a particular case of 3D.
>> Lets say 2D is a 3D with just one z-component. From my prospective, it has
>> to work
>> for 2D if it does for 3D. Opposite is not necessary true though.
>>
>> 2) If I comment the writer out, the program still crashes with the same
>> error.
>>
>> 3) All my images are in the Analyze75 format
>> and while using the other ITK filters I have not had any problems so far.
>> (I mean with ITK Analyze reader/writer, except orientations, of course).
>>
>> Do you mean that even though my executables did not complain,
>> the results I was getting could be wrong since I used ITK Analyze
>> reader/writer?
>>
>> If so, in what fashion could the final results be wrong?
>>
>> Is it error-prone for some particular platform/compiler
>> (Linux Debian with gcc 4.1.2 in my case) or it is more general case?
>>
>> How severe does it affect the final results?
>>
>> Thanks for your help,
>>
>> Alex
>>
>>
>> Bill Lorensen wrote:
>>     
>>> Oleksandr,
>>>
>>> There are some known problems in the ITK Analyze reader/writer when
>>> the images are 2D and not 3D. I think the read part has been fixed
>>> recently. However, the write part still has problems. If your images
>>> are 3D, then all should be fine. Until we fix this 2D Analyze image
>>> problem, I'm afraid you cannot run the filters.
>>>
>>> Bill
>>>
>>> On Sun, Jun 1, 2008 at 1:07 PM, Oleksandr Dzyubak <adzyubak at gmail.com>
>>> wrote:
>>>
>>>       
>>>> Hi Bill,
>>>>
>>>> This time I try to be more accurate.
>>>>
>>>> 1) I downloaded ITK from CVS, compiled with the RelWithDeb flag, and
>>>> installed on my Linux box.
>>>> 2) I have Debian Etch with gcc 4.1.2
>>>> 3) The example itkSignedMaurerDistanceMapImageFilterTest.cxx was taken
>>>> from ITK distro and not from IJ.
>>>>
>>>>
>>>> Insight/Testing/Code/BasicFilters/itkSignedMaurerDistanceMapImageFilterTest.cxx
>>>>
>>>> 4) Example was compiled in debug mode.
>>>> 5) As you advised, the example was run on both SquareBinary201.png and
>>>> SquareBinary201.hdr.
>>>>
>>>> Results.
>>>> As you predicted, the example has processed the *.png image taken from
>>>> ITK
>>>> distro resulting
>>>> in a nice looking map.
>>>>
>>>> dzyubak at debian: /BUILD$ ./SignedMaurerDistanceMapImageFilterTest
>>>> SquareBinary201.png test_png.hdr
>>>> WARNING: In /root/Insight/Code/IO/itkAnalyzeImageIO.cxx, line 1280
>>>> AnalyzeImageIO (0x8169a98): ERROR: Analyze 7.5 File Format Only Allows
>>>> RPI,
>>>> PIR, and RIP Orientation
>>>>
>>>> However when I tried to run it on a real stuff (all my images in
>>>> Analyze75
>>>> format), the same image but
>>>> taken from IJ archive (SquareBinary201.hdr), it crashes.
>>>>         
>>