# Keypoint orientation with the oFAST from Rublee's ORB

I've just read the papers from Rublee et al. (ORB: an efﬁcient alternative to SIFT or SURF) and Rosten et al. (Machine learning for high-speed corner detection) (=fast-detector). Rublee tries to explain the oriented-FAST-Detector an its improvements.

But there is one thin I can't understand. He assumes that a detected corner is not the real centroid of this corner. He uses the image moments to determine the real centroid. He then computes the atan2 to get the orientation of the intensity patch.

The Question is: What will he do with this orientation? I don't see any sentence about a shift of a possible corner-point using the orientation and den centroid.

-

The point descriptor usually requires samples at some specific locations from around the detected point.

If you have point location refined and orientation assigned, you just shift and rotate the locations before computing point descriptor.

Some simple descriptors require samples at discrete locations (e.g. 15x15 pixel image patch) and applying shift+rotation will make the sample locations non-discrete (the patch is arbitrarily rotated and shifted) and you have to use bilinear or bicubic interpolation to take the pixel values.

Here is a sample of detected points - notice the corresponding patches are rotated:

To get e.g. 64x64 matrix of values for each patch, one has to sample points rotated accordingly.

-
So the position of the current edge is shifted and rotated to the "real" position? The paper doesn't tell me that but this usage of the orientation would be not far to seek. –  Mr.Mountain Feb 12 '13 at 13:29
You can take a look on the OpenSURF implementation. There are PDF notes on the same page explaining some details about the descriptor construction. I think the same rotated sampling should be used for ORB (or BRIEF, respectively). –  Libor Feb 12 '13 at 14:39