[Insight-developers] DanielssonDistanceMapImage segfaults

[Gaetan Lehmann]

Hi Luis,

On Fri, 31 Mar 2006 15:43:32 +0200, Luis Ibanez <luis.ibanez at kitware.com>  
wrote:

>
> Hi Gaetan,
>
> Feeding a 2D image into a pipeline that is defined for 3D images
> is not a good practice. Specially if you are using filters that
> require neighborhoods (as it is the case for the Danielsson distance
> map).
>
>
> Some questions:
>
>    1) Why are you passing a 2D image to a 3D pipeline ?

It's the result of the AccumulateImageFilter, which produce 3D images with  
1 pixel on the accumulated dimension. I can convert it to a real 2D image,  
but my idea was to produce a 3D image from the 2D image. This image is a  
good candidate to do that because it have the same phisical size, and so  
it only needs to be resampled.
Going from 3D to 2D and then come back to 3D is discutable, but in that  
case, it gives the result needed to continue the segmentation.

Anyway, the question is not why I do something which make this filter  
segfault, it is why this filter segfault :-)

>
>    2) If you want to process a 2D image,
>       why don't you define a 2D pipeline ?

see above

>
>    3) What could be the result of a distance in 3D to a 2D slice ?

for the distance, I don't think the image dimension should have an effect  
- except if the borders have an effect on the distance.

>       do you want to manage the singularity of the 2D slice in 3D ?
>

I'm not sure to understand the question. I hope the answers above are  
enough :-)

>
> There are *many* ND operations that you cannot do in a N-1 dimensional
> image. E.g. any derivative operation, morpho math, Markov random fields,
> just to mention a few.
>
>
> We could add a check to the Danielsson distance map in order to require
> the input image to have at least three pixels along every dimension.
> The check could throw an exception with the input image does not satisfy
> this requirement. This will prevent the filter from crashing when it is
> feed with degenerate images.

I think that's the minimum to do: the filter should not lead to a  
segmentation fault because the input image do not have the correct  
properties for the filter !
However, as said before, I think the filter should be able to produce the  
correct output on an image with 1 pixel on 1 or several dimensions, if the  
borders have no effect on the distance map - I have not checked if that's  
the behavior of this filter.

Also, there are many classes which are resulting to segmentation fault in  
ITK if the parameters are not (correctly) initialized - including some of  
mine. I have noticed that while running all the methods in python wrappers  
to get the non-wrapped types.
I'll try to post a list soon, as well as some patches

Gaetan

>
>
>
>    Luis
>
>
>
> -------------------
> Gaetan Lehmann wrote:
>>  Hi,
>>  I'm trying to use the DanielssonDistanceMapImageFilter with some  
>> images  whith a size which is sometime 1 on one dimension, and the  
>> filter segfault  in that case. It seem that the  
>> ReflectiveImageRegionConstIterator try to  access pixels outside the  
>> image (!) and that make
>>        components->GetPixel( here ) = offsetValueThere;
>>  fail in UpdateLocalDistance() method.
>>  I have no idea how to fix that, so I tried to pad the image by one on  
>> all  faces, apply the distance map filter, and crop the pixel, but  
>> again I get  a segfault. I have to use the pad and crop filters AND to  
>> call Udapte() on  my DanielssonDistanceMapImage before calling Update()  
>> on the last filter  filter of my pipeline to finally get the result  
>> without segfault.
>>  The problem is easy to reproduce: write a pipeline
>>  reader 3D
>> danielsson distance map 3D
>> writer 3D
>>  and read a 2D image (cthead1.png for example) is enough.
>>  It seems that there is several bugs which should be fixed in   
>> DanielssonDistanceMapImage class :-)
>>  Gaetan
>>



-- 
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