🚀 go-pugleaf

In article <1993Jan26.012844.15569@usl.edu> twc@swamp.cacs.usl.edu (Tat W. Chan) writes:
>     1. Debugging a large program which input data is huge and not 
>        well-structured (as it is common in the domain of this newsgroup), 
>        is there any effective ways to locate the bugs? Should we deal with 
>        the program first, or the data first, or both?
>
>     2. If there is any good way to solve #1, is it different from debugging 
>        techniques in other domains in which the input data is not so intensive?

When debugging a typical image processing algorithm, conventional debuggers
are of little help.  The vast amount of data that image generates makes it
fruitless to examine each number.

The most useful way I know of in dealing with is using a model data before
you use a real data set.  For example, if you are looking for a centroid,
use a picture that consist of 0 and 255 only, and that forms a perfect
square.  Of course, this data is generated, not acquired.  If the square
works, then try a rectangle, and so on.

In CT image reconstruction algorithm testing, I use either a thin wire to
see if the algorithm reconstructs a point.  Or better yet, use simulated
data.

Some algorithms take hours, or even days in development stage.  Use lower
resolution in debugging stage.

Have a standard set of simulated data that you use every time you make any
modification to the algorithm.

That's all I can remember at the moment.

James Choi