[Insight-users] Distance transform in a hurry

[Benjamin King]

Hi Richard,


thanks for pointing me to your paper. Due to the beauty of Open  
Access, I'm currently checking it out.

Can you give me some advice on how to run perfDT3D manually? I have  
tried to provide the six parameters that the perfDT3D usage tips  
display, but the code requires argc==8 and there seems to be a  
disparity for the usage of argv[1]:

iterations = atoi(argv[1]);
...
IType::Pointer inputOrig = readIm<IType>(argv[1]);

'make test'  works, though, so this is probably a misconception on my  
behalf.

The code submitted with your paper compiles well and the tests are  
working

  The rleTest in the latest code at http://voxel.jouy.inra.fr/darcs/ 
contrib-itk/parabolicMorphology does not compile. I just commented  
out the body of the doRLE function for the time being. On my machine,  
all tests with the exception of Perf pass, while Perf ends with a  
segmentation fault. Is this related to doRLE?


> http://hdl.handle.net/1926/1370
> [...] I only discovered the generalized DT
> package after I wrote most of it and never got around to sorting out
> the details of how they matched up.

The code that I turned up with is not as nicely decomposed into small  
functions as yours. All the loops and decomposition for threading is  
handled in GenerateData.

The algorithm that is implemented by  
GeneralizedDistanceTransformImageFilter needs a temporary vector that  
manages a lower envelope of a set of parabolas. A lot of runtime goes  
into finding intersection points and adding/removing parabolas to  
this vector, about 35% on my machine.
The sampling of the envelope takes a little less than 20% runtime.

While I haven't read the original paper that you reference for  
details on the algorithm, I haven't seen code concerned with  
intersections in doLine(). Therefore I think that the methods are  
somewhat different.


> It is also loads faster for distance transforms, is fully threaded and
> there are helper classes for doing binary erosion and dilation. I
> personally think that the approach of both existing ITK signed DT
> filters on using a 3x3 morphological operation to introduce a zero
> contour is wrong (it is definitely wrong at corners) because it
> introduces a somewhat pointless asymmetry between foreground and
> background so the signed DT in the parabolicMorph package doesn't do
> that.

Can you elaborate on that? What would you expect to happen on the  
corners of a square, for example?


Regards,
   Benjamin