Code Organization and Algorithm

The algorithm my code follows is very simple. It can be described at a high level as follows:

Steps in the Program

1. Interpret the command line.
2. Read in the source image provided on the command line.
3. Perform the Marr-Hildreth edge detection algorithm.
   1. Apply a Gaussian filter to the image (using code from Project 2).
   2. Calculate the Laplacian of the result.
   3. Find zero crossings, and determine if the gradiant magnitude at that point is above the threshold to be considered an edge.
4. Perform the Hough Transform into an accumulator space.
   1. For each edge point detected by the edge detector, increment the counters for corresponding lines in the accumulator space.
   2. Blur the accumulator space (using code from Project 2).
   3. Threshold the accumulator space.
   4. For each blob remaining in accumulator space after thresholding, calculate its corresponding line representation. I do this just by finding the maximum bin count in the blob and using its line representation.
5. Draw the lines found onto the original image.

Code Organization

To save paper, I did not print out code that I reused from previous projects. This code is still included in the electronic version, but I doubted you wanted 25 additional pages just to see my Fourier Transform and filtering code or the code I use to parse and write PPM files, when you've already verified that this code works.

The files required to compile are as follows:

• filters.c: Includes the code to apply the filters I implemented for Project 2. Most relevant for this project is the code that applies a Gaussian filter. (Hard copy not included)
• findlines.c: The main file for my line detector. Includes main(), global variables, handling of command line parameters, and also handles drawing the lines that are detected onto the input image before writing the result back to a file. (Hard copy included)
• findlines.h: The header file for the project, with all the data structures and function prototypes. (Hard copy included)
• fourier.c: Handles the transform to and from the Fourier domain. (Hard copy not included)
• hough.c: Handles the Hough Transform to accumulator space as well as the functions to blur and threshold the accumulator space, and finally to identify the lines represented by the remaining blobs. (Hard copy included)
• input_ppm.c: My standard PPM input functions. (Hard copy not included)
• marr.c: Handles the Marr-Hildreth edge detection. Includes functions to apply a Laplacian to an image, detect zero crossings, and determine if a point qualifies as an edge based upon its gradiant magnitude and Laplacian value. (Hard copy included)
• ppm.h: Header file required by my standard PPM I/O functions. (Hard copy not included)
• write_ppm.c: My standard PPM writing functions. (Hard copy not included)

Running & Compiling the Program

The program is very easy to run. Run "findlines" (with no parameters) to get usage information. Since this algorithm has a lot of parameters to play with, most of the time the defaults aren't good enough. However, you can try a default run by typing "findlines < input ppm file >". Note that due to my algorithm for detecting lines in the accumulator space, with bad parameters the program may appear to hang during the Hough Transform stage. If this happens, you may wish to kill the program and restart with better values, since the results likely won't be worth the wait.

Running the program creates the following output images: out.ppm (edges from Marr-Hildreth), ht.ppm (the accumulator space), ht_blurred.ppm (the blurred accumulator space), ht_thres.ppm (the thresholded accumulator space), and final.ppm (the final result).

Examples:

• findlines -t 6 -s 90 -tres 256 -rres 256 -hthres 90 cbox.ppm
• findlines -t 20 -s 60 -rres 512 -tres 512 -hthres 45 -hsig 0 zelda64.ppm
• findlines -t 18 -s 50 -tres 512 -rres 512 -hthres 60 -hsig 0 castle3.ppm

Results and Analysis

As usual, to make sure that my code was working, I tested the program at various stages with simple images. Below is an image of a white square on a black background run through the program at various stages.

Original image	After detecting edges
After Hough Transform	Final result

A simple box run through the entire algorithm

Once I knew the program worked for simple images, I tried it on some more complex images. Figures 1 and 2 show additional results from the Marr-Hildreth edge detector. Figures 3 and 4 show addition examples of the Hough Transform. Figures 5, 6, 7, and 8 show examples of images, the final result, as well as the intermediate results. More examples can be found on my web page at: http://www.cs.utah.edu/~wyman/classes/imp/edge_detecton/index.html.

Really, the code for this project wasn't all that hard, given the code I had already done for project 2. The tough part about this assignment was figuring out what parameter values would give good results. Since I had 6 parameters to play with, this was not an easy chore. Eventually, I had to settle for "good" results from my program instad of going for that "perfect" detection of every line.

My parameters were as follows:

• The standard deviation for the Gaussian blur (applied before taking the Laplacian for the Marr-Hildreth algorithm).
• The threshold used for the gradiant magnitude in the Marr-Hildreth algorithm.
• The resolution of the accumulator space.
• The standard deviation of the Gaussian (used to blur the accumulator space).
• The threshold used on the accumulator space.
• A window size to determine how close 2 blobs in the accumulator space had to be before considering them a single blob.

To add to the confusion, I often got identical or very similar results from two very different areas of parameter space. Thus, getting results was a much more tedious process than in either of the two previous projects. However, once I got an idea how the parameters affected the result, the process went a lot quicker.

Effect of Parameters on Result

Gaussian for Marr-Hildreth

A higher standard deviation made Marr-Hildreth detect more edge pixels, but generally the results got noisier as it increased.

A low standard deviation made Marr-Hildreth detect fewer edge pixels, but the edges tended to become more "fuzzy", which at times confused the line detector, making the program overlook seemingly obvious lines.

Images showing this effect of this parameter are shown in Figure 9.

Threshold for Marr-Hildreth

When blurring the input image further didn't help reduce the number of spurious edge points (or edges from background objects or texture), the threshold could be increased to help offset the effect.

Similarly, if a really low standard deviation was used, this threshold could be decreased, allowing more edges to be detected.

Resolution of the Accumulator Space

If the number of edge points detected by Marr-Hildreth was very high (either due to an image with plentiful edges, or a very large image), then often many points intersected in the same place in accumulator space. Since I used a 256 level greyscale image for my accumulator space, this caused problems if more than 255 points intersected in the accumulator domain. To solve this problem, I would increase the resolution of the accumulator space.

Similarly, when the image was very large, then a small accumulator space gave very imprecise results, resulting in lines off by 2 or 3 pixels or angled noticably wrong. Here too, increasing the accumulator space helped.

On the other hand, the larger the accumulator space, the slower the program ran, so the smallest possible resolution was desirable.

Gaussian for Accumulator Space

Blurring the accumulator space helps merge together two seperate peaks which actually belong to the same line in image space. However, it can also smooth seemingly obvious peaks into the background (especially if they're very focused, 1 pixel peaks). Thus, having a peak with neighbors belonging to the same line makes a lower standard deviation desirable. On the other hand, when the accumulator space has very focused peaks, or nearby peaks which belong to separate lines, a high standard deviation is desirable.

Threshold for Accumulator Space

After blurring the accumulator space, all pixels with a count smaller than this threshold are discarded. Obviously if this threshold is too high, few, if any, lines will be found.

On the other hand, if this threshold is too low, there will be too much information in the accumulator space for the line detector to reliably locate lines. In this case, my algorithm takes a long time to compute results and they are generally very poor.

Window Size in Accumulator Space

Ideally, once the accumulator space has been thresholded, each disconnected "blob" of pixels represents a single line in image space. In practice, there always seemed to be blobs with noisy outliers, just one or two bins away from the main group. Generally, these actually didn't represent new lines, but rather just resulted from noisy results from the Marr-Hildreth edge detector. Changing this window size determines how disconnected blobs had to be before being considered distinct lines.

Making this really low results in lots of spurious, nearly identical lines. Making this parameter too high results in combining distinct lines together.

Figures

On the following pages are the figures referred to in the text above.