Yes. That sounds very similar to the conceptual algorithm we used. We started with the lowest point (GDDM uses "ass-back'ds coordinates" with (0,0) being bottom left) and then move around the thing in one direction until you get back to where you started from.

There are various optimisations that can be applied. For example, when you look for the second point, you can start sweeping (in either direction) from the horizontal in that direction because you know that there is no point lower. You can also apply the same optimisation to each of the left-most, right-most and top-most points, which allows you to start in four places and progress them all (moving in the same direction) until they connect up with one of the other three. You can also set out in both directions from each of the ordinal points and progress 8 moves concurrently, theough the terminating conditions are more complex.

Because you're starting (say) lowest and moving right (anticlockwise) you can constrain the points you look at, and also look at them in a defined order of probability--though I don't remember the details of the sorting criteria.

There was also this thing about using vector math which I recall not properly understanding the principles of even though I coded it and made it work. Needless to say, whatever understanding I did have has long since vacated my head.

The hardest part as I remember was preventing picking up spurious outlying points. The low-pass filter removed a lot of them but still occasional hotspots made it through. The mechanism for excluding those was a statistical thing that eliminated points that weren't part of a localised cluster. Darn it I wish I could remember more.