![](bg6.png)
ference for each factor is not very high in general
(around 2dB on average), a factor-dependent trend re-
garding the average difference can be seen.
While our approach achieves a higher PSNR for large
resizing factors (greater than 6.2), the converse is true
for small resizing factors (less than 3.1). If little ac-
tual interpolation is required (e.g., for factors like 1.0,
2.0 or 3.0), the PSNR differences are smallest on aver-
age. Conversely, they amount to up to 4 dB for quasi-
pathological cases like resizing factors of 1.9.
Although this may seem relatively high, thorough
investigation shows that high differences are mainly
caused by sub-sample shifts of the image introduced
by our algorithm. Interpolating in the integral im-
age domain partly ”moves” the area associated with
each interpolated column and row to their correspond-
ing neighbours, thereby introducing a sub-pixel shift
when reconstructing the image. As this augments the
error signal, the PSNR increases. Assuming that most
practical applications are not affected by shifts of this
magnitude, the quality difference between our bilin-
ear resizer and OpenCV’s can be considered accept-
ably small.
4.3 Performance
As state-of-the art object detection algorithms make
heavy use of integral images on multiple scales as
explained in section 1, we modified one of them –
OpenCV’s LBP based object detection algorithm –
as an example. Note that this can be done for other
multi-scale integral-image-based object detection al-
gorithms in a similar fashion, making the subsequent
results applicable to them as well.
While OpenCV’s original LBP detector imple-
mentation resizes the input image in the image do-
main and computes its integral image on each scale
(see figure 5 left), our modification uses the integral
image of the original image and resizes it in the inte-
gral image (II) domain (see figure 5 right). The actual
detection operations on the resized integral images re-
main unchanged. However, our modification does not
require the integral images to be computed at each
scale. Note that this theoretically allows discarding
the input picture as soon as the first integral image
is calculated. This can save a significant amount of
memory, e.g., on embedded systems, when the input
image is not needed otherwise. As the default resizing
factor used by OpenCV is 1.1 per scale in each dimen-
sion, our approximate resizing approach described in
section 3.1 is used.
In order to assess the influence of our resiz-
ing approach on object detection performance,
we trained the LBP detector with OpenCV’s face
detection training data set and a negative data set from
http://note.sonots.com/SciSoftware/haartraining.html.
Subsequently, we assessed its detection performance
using the four CMU/MIT frontal face test sets from
http://vasc.ri.cmu.edu/idb/images/face/frontal images.
The test data set includes eye, nose and mouth co-
ordinates for each face in each of the 180 pictures.
A face is considered detected if and only if all of
the aforementioned coordinates are within one of the
rectangles returned by the LBP based detector. The
detection rate is determined as the ratio of the number
of detected faces to the total number of faces.
In total, the detection rate does not change, i.e.,
both, OpenCV’s and our modification’s, detection
rates are exactly the same, namely 46.19%. It should
be noted that not all detected faces coincide com-
pletely, i.e., the detected rectangles differ slightly due
to the sub-pixel shift introduced by our approach on
smaller scales as explained in section 4.2. In addition,
15% of all pictures exhibit differences in the num-
ber of detected faces, which is mainly due to fact that
the detector’s training was performed using regularly
resized training data. We conjecture that, when us-
ing our resizing approach during training as well, the
aforementioned differences will possibly vanish.
In order to assess the performance gain of our
modification in terms of execution time in a fair way,
we do not perform execution time measurements for
our unoptimized modification and the highly opti-
mized original OpenCV code. Instead, we deduce
the performance gain as follows: As our resizing ap-
proach in the integral image domain is identical to
bilinear interpolation in the image domain in terms
of operations (see section 3.1), our modification does
not impact the resizing speed. Conversely, as our ap-
proach does not require integral image calculations at
any scale but the first (see above), the remaining inte-
gral image calculations do not need to be performed.
Therefore, the execution time of these integral image
calculations relative to the detector’s total execution
time is equivalent to the potential speedup of our ap-
proach compared to the current OpenCV implemen-
tation.
For the accurate measurement of single functions’
execution times, rdtsc (Intel, 2012) commands are
placed before and after the corresponding function
calls inside the OpenCV code. We use the aforemen-
tioned CMU/MIT test set and execute the detector a
total of 110 times for each image – ten times for cache
warming and 100 times for the actual time measure-
ment as described in section 4.1. To address the ques-
tion of scalability, two additional test systems with
comparable software configurations are used for this
evaluation: a mobile system (henceforth referred to
SpeedingUpObjectDetection-FastResizingintheIntegralImageDomain
69