Seite **1** von **1**

### sliding_window_faster

Verfasst: **11. Jun 2010 13:38**

von **triality**

Regarding sliding_window_faster:

1. We are building the integral image by computing the magnitude and orientation of the *whole* picture.

1.1 Afterwards we compute the integral image step by step. The histogram integral_image( end, end, : ) equals the histogram which would result by using the function comp_cell_hist on the whole picture.

The problem:

If we use the slow sliding_window approach, we compute the gradient/orientation for every patch. In the fast approach as described above, we pre-compute it for the complete image. (The cells for the fast approach are computed using formula (16) of the project.pdf.) This leads to different magnitude/orientation values, which leads to different histograms for every Cell.

Is the approach described in 1.1 correct? Especially regarding the computation of the magnitude.

### Re: sliding_window_faster

Verfasst: **11. Jun 2010 14:39**

von **Christoph Vogel**

There should be no difference in the gradients, regradless whether it is computed over the whole image or just over a small patch. The values at the pixel coverd by the patch should be equal to the corresponding values in the image.

Regarding your comment 1.1 this seems to be the case for you.

Did you account for the definition of a value of the integral image at a pixel? It is the sum/integral of the whole region from the upper left corner including the local value at that pixel. So if you want to get the sum over a region you should subtract/re-add the region-sums/integrals you do not want to be contained.

A further point to consider might be the prevention of border effects, as described in the last exercise hour (Fri Jun 11).

If you are setting the gradients at the borders of the patch region to 0, you will have to compensate for this effect by using a slighly different extraction method as described.

### Re: sliding_window_faster

Verfasst: **14. Jun 2010 00:01**

von **triality**

In our implementation there is quite a difference in the gradients.

For the sliding_window_faster, we compute the gradients over the whole image. For example see this magnitude image "mag1" of a randomly generated 32x32 picture:

http://img139.imageshack.us/img139/9360/mag1.png
But if we use the normal sliding_window function, four gradients (16x16 subpictures) will be computed, resulting in "mag2":

http://img690.imageshack.us/img690/9117/mag2.png
For comparison the next picture shows the difference "mag1-mag2" between both:

http://img534.imageshack.us/img534/60/differencej.png
Obviously this results in different histograms. Can you tell us anything about it?

### Re: sliding_window_faster

Verfasst: **14. Jun 2010 11:03**

von **Christoph Vogel**

Thank you for the pictures. What you are seeing here is exactly the case of border effects I shortly described in my last reply. The red areas are different, which are the borders of your sliding window. These artefacts occur because of the behaviour of the derivative filter you are using. The border pixel of your image don't have neighbours. Therefore you can not assign a decent derivative to the border pixel by applying a convolution with a filter mask. When applying the derivative mask to the pixel in the sliding window only you will have those border effects as well at inner pixel of the image. You can see that in the images provided.

In our case the border artefacts occur also in our training images and are therefore "learned" by the SVM.

There are several possible solutions to the problem. Most of the time the derivative mask is changed for pixel with incomplete support. The easiest solution is yet to ignore pixel close to the border of the image, by assigning 0 as derivative to all pixel in a certain region at the border. Albeit throwing away information those artefacts will then no longer affect your detector.

### Re: sliding_window_faster

Verfasst: **14. Jun 2010 15:30**

von **triality**

Still not sure how setting border pixel to zero works with the integral image.

Currently, the training is done with those artifacts. If we use our normal sliding window, we again have artifacts. Assuming we ignore the _faster method and worked with the artifacts (training with artifacts, detection with artifacts) do you think this would affect the detection?

### Re: sliding_window_faster

Verfasst: **14. Jun 2010 20:27**

von **Christoph Vogel**

The larger the training set the more the results will be unaffected.

I actually didn' t and will not do a study on how much training with border artefacts will hurt your performance here.

You might loose a percent in ERR or more or maybe nothing at all.

In general you might introduce a pattern that the SVM might learn. But if you assume that the artefacts created are gaussian distributed, you probably can show that in the limit case, these artefacts will not harm your detector.

You can set border pixel to zero by not including them in the cell histograms, simply choose different 'corner' pixel for cells affected.