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

[Bill Lorensen]

Oleksandr,

An optimistic person might consider this progress. We appreciate your
efforts to help us resolve this. What 3D dataset are you running? I'll
try to reproduce the problem if possible.

Thanks for your patience,

Bill


On Tue, Jun 3, 2008 at 4:05 PM, Oleksandr Dzyubak <adzyubak at gmail.com> wrote:
> 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.
>>>>>
>>>
>>>
>
>