TODO

You can help the ShapeMatcher project by doing one (or more) of the following things:


1. Develop a visual interface as an alternative to the current command-line one. 
   You would probably want to make ShapeMatcher be a WIN32 Windows application rather 
   than a console. See the main(...) function in ShapeMatcher.cpp. There you'll find 
   a sketch code for converting it into a WinMain(...) function. Changing this would 
   allow any visual interface or front-end to call ShapeMatcher as a process without 
   having to deal with a console. You'll have to resolve how to redirect cout, cin 
   and cerr, so that they talk to your interface.


2. Improve performance of Flux Skeleton algorithm

The Flux Skeleton developed at McGill by Kaleem Siddiqi's group is the
best skeletonization code in terms of the quality of the skeletons that it
yields. In this algorithm, not only the x-y coordinates of the skeleton points
are accurate but more importantly their radii are too. The problem with
this code is that it is really slow. The good news is that it can be fixed, since
the main reason why it's so slow it's because no once cared about performance when it
was written. Here are some thoughts about a possible way to go about improving 
the code.

The code is slow simply because the guys that wrote it used a very brute force 
approach to "thin" a shape. The problematic thinning method iterates through all 
the pixel in a shape looking for the closest on the shape boundary or something 
like that. So, the idea would be to have a more efficient data structure to
quickly find the closest points or some other less brute force
strategy (e.g., using the ANN library already included and use elsewhere in 
the project). The time-consuming problem is located in one single function, which 
can be changed without understanding much about what is going on elsewhere in the code.

This is what we know about the super slow, brute force function:

It starts in the method create_shape_DivArr in the file
DivergenceSkeletonMaker. This function traverses all points in the
image and takes considerable time for actual object points. It calls
getValue in the DivergenceMap which in turn calls getGradValue in
DistanceTransform, which in turn calls getValue in itself which calls
distToPt in DiscreteSegCurve (... hmmm...) and this function seems to
be looking for the smallest distance between this curve (all points of
the curve) and the give point (given in create_shape_DivArr). I guess
there is always just one curve though; the curve that bounds the
object.

Please, send me (dmac@cs.toronto.edu) your modifications to the code if you manage 
to fix this problem.


3. There are a number of subproject to do related to making certain parts of the
   code run in parallel, such as in a graphics card (eg, the thining algorithm in 
   the FLuxSkeleton) and on multicore processors. If you are interested in doing this,
   eg, maybe for a course project, let me know and I'll give you more details about 
   how to proceed.