[SciPy-user] hough transform again

stephen emslie stephenemslie at gmail.com
Tue Aug 22 09:57:35 CDT 2006

It could be that Stefan's hough is fast because it uses only one for loop,
and lots of array operations, which I believe are fast.

Speed is definitely going to be an issue for me, as I'm going to need to be
able to process a video feed in real-time. But I'd like to try and get
things working with scipy and radon to start, and then look at speeding
things up.

Thanks for the link.
btw, hope you dont mind if I send this to the list too. Perhaps someone will
be able to give some more insight into hough, radon, inverse radon, speed,


On 8/22/06, Brent Pedersen <bpederse at gmail.com> wrote:
> hi again, this page makes the inverse radon seem fairly do-able:
> http://www.owlnet.rice.edu/~elec431/projects96/DSP/bpanalysis.html<http://www.owlnet.rice.edu/%7Eelec431/projects96/DSP/bpanalysis.html>
> i'm going to try to implement.
> at least all the tools are in sci/num-py, just have to put them
> together...
> i still wonder why the stefan's hough is so much faster than scipy's
> radon, i guess the imrotate in radon must be pretty expensive.
> -b
> On 8/22/06, stephen emslie <stephenemslie at gmail.com> wrote:
> >
> >
> > also, have you seen radon() in scipy.misc ?
> > > if only there was an inverse_radon().
> > >
> >
> >
> > I'm taking a look at it now. The Radeon transform looks like it might be
> > more effective than the Hough transform. Even so, I think it would be nice
> > to have a Hough transform in scipy. Of course there's still that problem of
> > the inverse transform as you say. It would definitely be handy to have!
> >
> > Stephen
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/scipy-user/attachments/20060822/dfc7ca25/attachment.html 

More information about the SciPy-user mailing list