[vtkusers] vtkSubPixelPositionEdgels HELP !

[Mathieu Malaterre]

Hi Ken,

  Here is the ouput of gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 18287)]
0x4048e036 in vtkFloatArray::GetTuple (this=0x8227168, i=299146,
tuple=0xbfffeaf0)
    at /shalom/data/mmalat/VTK/Common/vtkFloatArray.cxx:269
269         tuple[j] = t[j];
Current language:  auto; currently c++
(gdb) bt
#0  0x4048e036 in vtkFloatArray::GetTuple (this=0x8227168, i=299146,
tuple=0xbfffeaf0)
    at /shalom/data/mmalat/VTK/Common/vtkFloatArray.cxx:269
#1  0x416121a6 in vtkSubPixelPositionEdgels::Move (this=0x8226cf0,
xdim=512, ydim=512, zdim=1, x=138, y=584,
    img=0x42abb008, inVecs=0x8227168, result=0xbfffec60, z=0,
spacing=0x8226128, resultNormal=0xbfffec50)
    at /shalom/data/mmalat/VTK/Graphics/vtkSubPixelPositionEdgels.cxx:138

#2  0x41611f0a in vtkSubPixelPositionEdgels::Execute (this=0x8226cf0)
    at /shalom/data/mmalat/VTK/Graphics/vtkSubPixelPositionEdgels.cxx:83
#3  0x4057769d in vtkSource::ExecuteData (this=0x8226cf0) at
/shalom/data/mmalat/VTK/Common/vtkSource.h:145
#4  0x40575114 in vtkSource::UpdateData (this=0x8226cf0,
output=0x8226d68)
    at /shalom/data/mmalat/VTK/Common/vtkSource.cxx:391

But I think (I'm sure). It's due to the fact that my image is
anisotropic. The Move method doesn't handle anisotropic data. The move
method access data in memory and take into account spacing and origin. So
when origin = (0,0,0) and spacing = (1,1,1) everything is fine.
Otherwise....
To redo the crash you can just use canny.tcl and change either spacing or
origin of the image.

thanks a lot
mathieu


Ken Martin wrote:

> > Dear vtk gurus,
> >   I have send a mail a few months ago about
> > vtkSubPixelPositionEdgels
> > causing a seg fault, see:
> >
> >   http://public.kitware.com/pipermail/vtkusers/2002-June/011914.html
> >
> > Another point I would like to fix is that vtkSubPixelPositionEdgels
> > changes the Bounds (the Bounds of the output differ from the input)
>
> The Bounds will change because the output data is different from the
> input data. The positions of the pixels are changing, hence the bounds
> will often change as well. This is the correct behaviour. Re: the
> segfault, if you can send me a stack trace showing what line it died
> on (it is probably stepping off of the image due to rounding or
> something like that) I'll try to track it down.
>
> Thanks
> Ken

--
If all else fail read the instructions
Malaterre, Mathieu
The John P. Robarts Research Institute
Imaging Research Laboratories
http://www.imaging.robarts.ca/~mmalat