# Scale and Rotation invariant feature descriptors

Can you list some scale and rotational invariant feature descriptors for use in feature detection.

The application is for the detection of cars and humans in video captured by a UAV, using a multi-class classifier.

So far I have been looking at SIFT and MSER (which is affine invariant). I have also looked at LESH, LESH is based on the local energy model, but is calculated in a way that is not rotationally invariant, I have been trying to think of a way to make use of the Local energy, to build a rotationally invariant feature descriptor, I read here What are some free alternatives to SIFT/ SURF that can be used in commercial applications? ,that " if you assign orientation to the interest point and rotate the image patch accordingly, you get rotational invariance for free", but don't know if this is even relievent or how i could apply this to my problem, any help would be appreciated, thanks

• Use ORB (Oriented FAST and Rotated BRIEF) from the OpenCV library. – Harsh Wardhan Jan 7 '15 at 11:48

As far as alternatives to SIFT/SURF go, the question you linked provides very good answers.

There were two more questions I could read out:

• "how could I build a useful (e.g. rotation invariant) feature descriptor"?
• "regarding the statement from the linked question, how does he accomplish free rotational invariance?"

Building feature descriptors

This is a valid research topic. Good feature descriptors are not something just anyone can build in an afternoon. People publish articles when they successfully model feature descriptors with desirable properties. This is a reason that currently only a handful of state-of-the-art descriptors are used, and that is also what I advise you to do: find a feature descriptors that's good for your needs.

You can determine the dominant gradient, or orientation at an image patch (your feature area). Then, rotate the image patch so that the gradient is always looking in the same direction, e.g $0$ (upwards). E.g. if you had a |black->gray->white| and a |white->gray->black| image, their dominant gradients would be pointing left ($-90$) and right ($90$) respectively, and when you rotate them by this amount, you get the same images.

This way you will always calculate the descriptor on an image patch with the same dominant orientation (the rotated patch), and thus you achieve rotational invariance.

Another way to get rotational invariance for free, is to choose objects that are rotationally invariant. For instance, a circle or a ring is invariant to rotations.

Feature extractor: Run edge detection. For each neighborhood of NxN pixels, calculate edge direction and magnitude 2D histogram. Find all points that have high total magnitude, and high angular spread . Remove all points that don't have radial symmetry.

Feature descriptor: Find the center of each circular object. Since the object is circular, it has no dominant gradient angle. All angles are equal. Thus, a radial profile (sum of pixel value in polar coordinates) is an angle invariant descriptor.

By the way, that is one of the reasons that fiducials are manufactured as circles on electric circuit boards:

• we are talking about keypoint (feature) descriptors. If we were talking about features (interest points), then detecting circular patches might be useful -- they are rotationaly invariant in combination with every descriptor. But a descriptor calculated at a circular patch is not - a white circle with horizontal diameter in black, and with a vertical one would produce very different descriptors if rotationally invariant method isn't used – penelope Nov 3 '12 at 16:24
• @penelope, why not? Consider the following descriptor - a thumbnail of the patch, and you compare it with other descriptors with normalized cross-correlation. You can't mistake it with other objects in this way. – Andrey Rubshtein Nov 3 '12 at 19:44
• Sorry, I don't understand what you mean by "a thumbnail of the patch" can you explain? And the descriptor: normalized corss-correlation of you patch is what makes it rotationally invariant, not the fact that your patch was a ring or circle. – penelope Nov 3 '12 at 20:05
• @penelope, I guess now that I was not clear enough. I will try to expand it tomorrow. Thanks you for your comments. – Andrey Rubshtein Nov 3 '12 at 21:24
• Looking forward to it :) – penelope Nov 3 '12 at 22:41

I would rather look into KAZE / AKAZE, which perform equally good with significant speed-up. The deformation cases are also tolerated. OpenCV has recently obtained an implementation through GSoC 2014. You can find it here.

If you remap a local patch around a feature point to log–polar coordinates (with the origin in the point of interest), scale changes correspond to a translation along the log–radial axis, while rotations correspond to translations (with wrap-around) along the angular axis. If you then calculate the two-dimensional Fourier transform, translations in the radial and angular directions become phase shifts in the frequency domain. If you then calculate the absolute value of the Fourier transform, the phase vanishes completely, and scale changes and rotations of the original image patch become unnoticeable. So the absolute value of the 2D Fourier transform of the image in log–poolar coordinates would be your feature descriptor.

Well, at least in theory. In practice, you need to limit the radial extension of your patch. This means that you need to cut away a large part of your data before calculating the Fourier transform (which is really a Fourier series), so a translation along the log–radial direction in log–polar coordinates doesn't exactly correspond to just a phase shift in the frequency domain anymore, so the method isn't perfectly scale-invariant. I suspect that if you use some window function — without discontinuities — on the log–radius coordinate and multiplied it with the color intensity, this problem would be mitigated somewhat.

However, the feature descriptor it should still be perfectly rotation-invariant.

Reference: Scale Invariance without Scale Selection

You can also check FAST and BRISK.

• As far as I've searched, FAST is only a detector used with many different descriptor combinations. And, FAST and BRISK are already mentioned in the question the OP himself has linked, so I suppose he has information about the existence these methods already. – penelope Nov 3 '12 at 16:21