Jump to content

Talk:Hough transform: Difference between revisions

(→‎Can I get some pseudo-code...and possibly an amen: A little clarification on multiple counts.)
Line 5:
::: The problem is that pseudocode makes assumptions about implementation. I can write pseudocode that says "do this, then do this, then do this", but that tends to assume an imperative programming paradigm. It may be possible to have a universal pseudocode, but I doubt it. [http://www.reddit.com/r/programming/comments/5zypl/ask_reddit_is_therecan_there_be_a_standard_for/ This] is what I got the last time I poked around for one. That doesn't leave me hopeful. I've seen what happens when someone creates procedural pseudocode as part of a task description, assuming that it was part and parcel to what the task was supposed to accomplish, and then I've had to deal with reconciling the task's description against its intent and the languages which it accidentally made things structurally difficult for.
::: As I understand it, Hough depends a great deal on averaging values, which is going to be very difficult if you're only allowing yourself 1 bit of precision. You might try expanding that 1 bit to a larger range (i.e. an integer 0 for false, 255 for true, or a float type with 0 for false, 1 for true) before doing your operations, and then compressing back down to 1 bit prior to output. I'd make suggestions about how to choose range size, but I think that depends a great deal on your use case.) --[[User:Short Circuit|Michael Mol]] 19:40, 9 August 2010 (UTC)
::::Ummm. I guess I don't really mean pseudo-code but a human language translation of the algorithm the the C and TCL implementations are using. So this is what I mean by pseudo-code.<br />
Example:
<lang>function houghTransform
input: Image (boolean) where If Image(x,y) == True Then pixel at (x,y) is an edge pixel
Angular Resolution
 
for x from 0 to width of Image
store in a 2D array: x * cosine(theta from 0 to pi in steps of Angular Resolution)
 
for y from 0 to height of Image
store in a 2D array: y * sine(theta from 0 to pi in steps of Angular Resolution)
 
for x from 0 to width of Image
for y from 0 to height of Image
if Image[x,y] == True
store in a 2D array called accumulator: rho[j] = x*cosine(theta[j]) + y*sine(theta[j]) for all j
 
For each value of theta
histogram the rho values in accumulator where the bin size is equivalent to 1 pixel starting at 0 until all rhos are bins
store in a 2D array called houghSpace: the histogram where each histogram is indexed by theta and
the contents of each bin are the amount of "votes" for each rho value
 
Optional: Normalize houghSpace so the max votes are 255
 
Plot houghSpace where the x axis is Theta from 0 to pi in degrees
and y axis is rho from -sqrt(width^2+height^2) to sqrt(width^2+height^2) in pixels.
</lang>
 
::::It's obvious that there is no pseudocode that would work universally. But, in the case that a language can not directly implement some arbitrary pseudo-code, it is still possible for someone to read the pseudo-code, understand the general algorithm and then transform the pseudo-code into something that works in that language.
 
::::This is something that I had to do when I programmed all the sort functions in LabVIEW and MATLAB. All the pseudo-code for the sorts are written for languages with while loops and 0-Based arrays, where as LabVIEW only has the do...while loop and MATLAB uses 1-Based Arrays. It would have been impossible for me to program the sort functions in these languages without that pseudocode.
 
::::This is especially important here because the literature I've read on the hough transform is inconsistent about how to define the hough space. Is it theta from -90 degrees to 90 degrees? Or mayhaps 0 to 360, or 0 to 180? And is rho defined on the interval from -Image Height to +Image Height, or 0 to Image Height, or -sqrt(width^2+height^2) to sqrt(width^2+height^2) or 0 to sqrt(width^2+height^2). Is the granularity of the rho axis 1 or something more or less than 1?
 
::::Also, how are the votes tallied? Some people use some sort of gradient weighted method. Some just have a simple 1 vote per edge pixel. These happen to be the two most common voting metrics, but there are others.
 
::::I think all of these things should be specified in the task description, and the most comprehensive way to do that, in my opinion, is to provide some sort of pseudo-code. --[[User:Cferri|Chris Ferri]]
 
==PNG Image==
Anonymous user
Cookies help us deliver our services. By using our services, you agree to our use of cookies.