Wednesday, November 29, 2006
Local Shape Neighborhood Distance
Here are the results of some experiments using local shape neighborhood distances to compute the assignment cost function for the contour correspondence dynamic program.
First, on tools, with lambda=0, 0.5, 1, and 2:




Next, on forks (lambda=0,1,2):



And on mugs (lambda=0,1,2):



Again on mugs (lambda=0,.5,1,2):




Some comments:
First of all, the local shape neighborhood cost function seems to perform relatively well (for lambda > 0) on the mugs and the tools, but not on the forks. This is because the forks are actually quite different when local shape is considered, since one contour has prongs, while the other does not.
Second, the local shape neighborhood cost function seems to give good correspondence results for points with high curvature, while sometimes being sloppy about points along flat portions of the contours. This can be explained by looking at the cost matrices for the tools, mugs, and forks (darker means higher shape distance):



In each case, there are several dark rows and columns, which correspond to points on the two contours whose local shape doesn't match up well with most of the local shapes on the other contour. In other words, these rows and columns point out locations on the shape which are distinct. The other rows and columns represent undistinct local shapes on the contours. This points out a natural way to find salient local features of two shapes to be matched, which should significantly reduce the computational burden. The only drawback is that the cost matrix itself is quite costly to compute (as each element in the matrix is the minimum of a vector of local shape distances at different scales).
First, on tools, with lambda=0, 0.5, 1, and 2:




Next, on forks (lambda=0,1,2):



And on mugs (lambda=0,1,2):



Again on mugs (lambda=0,.5,1,2):




Some comments:
First of all, the local shape neighborhood cost function seems to perform relatively well (for lambda > 0) on the mugs and the tools, but not on the forks. This is because the forks are actually quite different when local shape is considered, since one contour has prongs, while the other does not.
Second, the local shape neighborhood cost function seems to give good correspondence results for points with high curvature, while sometimes being sloppy about points along flat portions of the contours. This can be explained by looking at the cost matrices for the tools, mugs, and forks (darker means higher shape distance):



In each case, there are several dark rows and columns, which correspond to points on the two contours whose local shape doesn't match up well with most of the local shapes on the other contour. In other words, these rows and columns point out locations on the shape which are distinct. The other rows and columns represent undistinct local shapes on the contours. This points out a natural way to find salient local features of two shapes to be matched, which should significantly reduce the computational burden. The only drawback is that the cost matrix itself is quite costly to compute (as each element in the matrix is the minimum of a vector of local shape distances at different scales).