Template Matching Invariant of Rotation
The first week of GSoC 2010 is over.In the mean time, I created a project on code.google.com . All my updates will be in that google-code svn repository, so if you have svn command line or svn client such as Totoise SVN you can checkout the source. I also have committed my openSURF experimentation source-code there in /branch/test folder. All my experimentation will be going into that folder.
As of now I have worked on different algorithms. I am planning to make CCV-TT modular so that any algorithm can be fit into it easily, so that it will be easy for future developments also. I will be writing the structure of the project in my next posts when I start coding for the Template Selection Tool.
So as the topic says I had experimented on contour matching. The source-code can be found on the googlecode repository. It includes the images in Images folder. The test images are :
The first image is the main image where the matching has to be done (say a frame from video/camera). The second is the template provided by the user. I have tried using SURF to find out the feature points and got only single feature point among them.Which was quite slow and will not be good to track (feature point was not at the center). Therefore I moved on to contour matching. Then I realized that contour matching may give very good results [cvMatchShapes(...) returns 0 ] when tried on the same template [the one cropped and transformed from the main pic]. But when tried on different picture’s templates [like the images shown] it gave quite bad results. You can see the difference in the drawing of the contour.
After seeing the contours [drawn in white in both ], the difference can be seen, it can give bad results or say can match to arbitrary curves on the surface/image. Therefore I thought of new plan, say contour-bounding-rectangle matching. The advantages and disadvantages are :
- Faster – It will involve very basic level math calculation.
- Saving into files/Loading from files, as these are of CvBox2D data type, it can be saved in files/loaded from files. This will also fasten the process a lot, reducing the time for finding contour for every image saved and calculation.
- minArea, maxArea for each contour- which will make it even more accurate.
- Detection and tracking of angles- from the rectangle that has been matched.
- It will not be very accurate.
- It will be more like shape matching.
As I had done experiments on this, You can see this clearly from results. Or you can checkout the google-code repository and perform the experiment by yourself.
As you can see the result, the actual contour bounding rectangle is matched. In case you want to know the contour matching results, just include the line
in the for loop where the draw_box(…) is used. This will return a double value. For the best detection it will return 0.This code basically has 2 funtions-to match the images, or to see the drawn contours. You can see the match(…) and check(…) for more details as it is documented. For match(…) you have to define PROCEDURE as 1 and for check(…) , you have to define PROCEDURE as 2. It is better explained in source.
Also for the linux users, just copy the main.cpp and you can compile it with g++. But you need to have openCV2.0 installed.
This is all for now. Next I will be coding the template matching tool on OpenFrameworks. I will be coding it as CCV mod. For the progress of the work, watch out this space or the googlecode project.