You're mixing together different things, so let's have a look at the big picture first.
For object detection / image matching, it's common to use a keypoint-based process:
- detect-and-describe keypoints in your database / learning set
- (optional) sort your reference descriptors in an acceleration structure (e.g. kd-tree)
- detect-and-describe keypoints in your query image
- find the nearest neighbors of your query descriptors and your reference set.
The descriptors can be real (floating-points, e.g. SIFT/SURF) or binary (bit-strings, e.g. BRIEF, BRISK, FREAK).
Binary descriptors are obtained through a specific design process: the operations used to compute the descriptor are quite different from the operations involved in real descriptors.
Let's take the example of SIFT vs. BRIEF.
The SIFT descriptor is made of histograms of the image gradient directions in a patch centered on the keypoint.
The BRIEF descriptor can be modeled by a 2-step process:
1. compute a real descriptor by computing the difference between small neighborhoods inside a patch centered on the keypoint
2. binaries descriptor by retaining only the sign of the difference.
I have also described this process in a blog post.
So no, you can't just binarize a floating-point descriptor, you need to use a dedicated one.
After that, it's up to you how you do the nearest neighbors queries.
In actual implementations, you may find some weird things about descriptor sizes.
The goal is t ensure that the size of a binary feature vector fits with hardware dedicated commands to compute Hamming distances in order to be very fast, and to allow the use of vectorized instructions such as SSE to compare different descriptors at the same time.