[Insight-users] crashes N-D Linear Time Exact Signed Euclidean Distance Transform
Oleksandr Dzyubak
adzyubak at gmail.com
Tue Jun 24 17:47:22 EDT 2008
Dear Bill,
Over weekend with help of a cup of nice strong doppio espresso
I had a chance to thoroughly repeat the tests again.
Now I write the detailed step-by-step report of what I have done.
1) Wiped all the libraries out in case that some libs are mixed and
affect the results.
2) Compiled and installed a new CVS version Insight_CVS_Jun_20_2008.tar.gz
3) Compiled the itkSignedMaurerDistanceMapImageFilterTest.cxx code from
"Insight/Testing/Code/BasicFilters/itkSignedMaurerDistanceMapImageFilterTest.cxx"
4) Used the image from "Insight/Testing/Data/Input/SquareBinary201.png"
which works fine.
5) Converted SquareBinary201.png to SquareBinary201.hdr (Analyze75) that
works fine too.
Summary.
Original version from "Insight/Testing/Code/BasicFilters" works fine for
2D case
with both *.png and Analyze75 image formats. The output images are
identical.
Now go for 3D case.
So in the original code I changed the image dimension line as below.
********** Begin Code Snippet ****
// const unsigned int ImageDimension = 2;
const unsigned int ImageDimension = 3;
typedef int InputPixelType;
typedef double OutputPixelType;
********** End Code Snippet ****
Since all my images are Analyze75 short (16 bits), I will use this
format whenever it is possible.
So running the 3D version on 2D image SquareBinary201.hdr gives an error
below.
*****Begin Error********
dzyubak at debian: /Images$ ./SignedMaurerDistanceMapImageFilterTest
SquareBinary201.hdr t.hdr
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.
Aborted
*********End Error*******
Well, as you said earlier, 3D version does not like running on 2D images
so lets make simple 3D image from the data set available from Insight
ToolKit.
1) For example, lets take "Insight/Testing/Data/Input/mri3D.mhd" and
convert it
to the Analyze75 format using the InsightApplications utility
"ConvertBetweenFileFormats".
For simplicity I preserve the original mri3D.mhd pixel type.
dzyubak at debian: /Input$ ./ConvertBetweenFileFormats mri3D.mhd mri3D.hdr
2) Now segment the input image and make an output binary image
using the "Insight/Examples/Filtering/BinaryThresholdImageFilter.cxx" code
with some lines changed.
********** Begin Code Snippet ****
// typedef unsigned char InputPixelType;
// typedef unsigned char OutputPixelType;
typedef unsigned short InputPixelType;
typedef unsigned short OutputPixelType;
// typedef itk::Image< InputPixelType, 2 > InputImageType;
// typedef itk::Image< OutputPixelType, 2 > OutputImageType;
typedef itk::Image< InputPixelType, 3 > InputImageType;
typedef itk::Image< OutputPixelType, 3 > OutputImageType;
********** End Code Snippet ****
dzyubak at debian: /Tmp$ ./BinaryThresholdImageFilter mri3D.hdr
mri3D_bin.hdr 60 200 0 255
3) And finally calculate EDT.
dzyubak at debian: /Images$ ./SignedMaurerDistanceMapImageFilterTest
mri3D_bin.hdr mri3D_bin_EDT.hdr
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.
Aborted
4) One more test.
There is a submission to the Insight Journal
http://insight-journal.org/midas/handle.php?handle=1926/196
"A Generalized Squared Euclidean Distance Transform with Voronoi Maps"
that can also calculate EDT plus it comes with the binary input images
in Analyze75 format
bigDataset.hdr; mediumDataset.hdr; smallDataset.hdr; square.hdr.
Lets make a test using those images.
If I run SignedMaurerDistanceMapImageFilterTest on those images,
I am also getting the same error as above.
5) Did I mention that it does not work with my Analyze75 images at all?
6) If I covert the Analyze75 images to DICOM, it still gives me the
error above.
What is wrong?
Thanks for your help,
Alex
Bill Lorensen wrote:
> 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.
>>>>>>
>>>>>>
>>>>
>>
More information about the Insight-users
mailing list