![](bg3.png)
and octaves are formed by the original image sub-
sampled by factors
1
2
(half-sampling) and
2
3
(two-
third-sampling). The original image is progressively
half-sampled to form the octaves, while the intra-
octaves are formed by progressives half-sampling of
the first intra-octave d
0
, which in turn is composed by
a two-third-sampling of the original image.
After the octaves and intra-octaves calculation, the
AGAST corner detector (Mair et al., 2010) is applied
to each one of them. All the points of each layer
will be evaluated as a keypoint candidate, and to be
elected a point must be salient among their intra-layer
and inter-layers neighbors. It means that each point
is compared with its neighbors in the same layer and
also with those in the above and bellow layers. Af-
ter the analysis of all octaves and intra-octaves, the
detection stages finally ends, producing a set of key-
points with space and scale coordinates, what means
that each one of them can be exactly located.
3.2 Keypoints Description
In this stage, around each keypoint, which has its co-
ordinates found in the previous step, a sampling pat-
tern is positioned. The BRISK algorithm uses a sam-
pling pattern similar to the one in DAISY descriptor
(Tola et al., 2010). However, it is important to note
that the use of this pattern is quite different. The
pattern relies on 60 equally spaced points located in
four concentric rings. In order to produce a scale
and rotation invariant description, the sampling pat-
tern is exactly scaled and rotated according to each
keypoint. The BRISK descriptor is composed as a bi-
nary string of length 512. This string concatenates
the results of simple brightness comparisons tests be-
tween each keypoint and its 60 neighbors in the pat-
tern (Leutenegger et al., 2011). This approach was in-
spired by the BRIEF method (Calonder et al., 2010).
3.3 Matching
Finally, to perform the comparison between two or
more keypoint descriptors, the Hamming distance is
used. This distance measures the number of differ-
ent bits between two binary strings and it represents
the degree of inequality of the descriptors being com-
pared.
4 M-BRISK
This section presents the mobile implementation of
BRISK algorithm and the main aspects concern-
ing to the environment where it was developed and
tested. This mobile implementation is called M-
BRISK (Mobile-BRISK).
4.1 Implementation
In order to implement the algorithm to be executed
into a mobile device, some issues had to be overcame.
The first of them was the fact that SSE2 and SSE3
instructions (Intel, 2006), the Intel’s SIMD instruc-
tions set (Flynn, 1972), were employed by Leuteneg-
ger et al. (Leutenegger et al., 2011) in their original
implementation of BRISK
2
. It was used as a crucial
resource to improve the BRISK performance at criti-
cal time-consuming routines.
SIMD instructions are available in ARM architec-
ture (ARM, 2012b), the most popular architecture of
mobile devices processors, just since the ARMv7 ver-
sion, through the NEON instructions (ARM, 2012a).
As these instructions are not available into all devices,
specially into the low-end ones, it was decided not to
use them in the present implementation. This choice
allows M-BRISK to be a more generic implementa-
tion, avoiding the dependence of specific mobile pro-
cessors and instructions sets. This approach also con-
stitutes a baseline assessment of the algorithm once it
is being evaluated in a most ordinary condition.
The sub-sampling routines, originally imple-
mented trough the SSE instructions, was replaced by
a bilinear interpolation function implemented using
the OpenCV library (OpenCV, 2011). This approach
showed to be efficient and applicable to a mobile en-
vironment while it kept robustness.
Another critical point is the sampling pattern rou-
tine. In the original BRISK implementation, as a
manner to obtain this pattern efficiently, 65536 sam-
ples are generated to each one of the 60 pattern points
during the algorithm initilization and stored in a look-
up table. These samples corresponds to all possible
discretized values of scale and rotation. There are 64
and 1024 possible values to each dimension, respec-
tively. The goal of this approach is to save running
time in the description construction of each keypoint.
However, such process is so time-consuming that its
use is prohibitive on mobile devices. Thus, to avoid
this problem, we chose to previously save a binary
representation of the look-up table in mobile device
memory card. Doing so, at the time of descriptors
construction the table is already completely loaded
into device memory.
Finally, during the matching routine, the SSE in-
structions were also used to improve the performance
2
The original BRISK implementation is available in:
http://www.asl.ethz.ch/people/lestefan/personal/BRISK
PerformanceEvaluationofBRISKAlgorithmonMobileDevices
7