Improving Hog allocations / Making a fast HOG version about imagefeatures.jl HOT 2 OPEN

I've been thinking about how to restructure the code to best support your suggestion. I've taken some inspiration from Mathematica's API, in particular, the GradientOrientationFilter.

Looking at the function reference for the ImageFeatures package I noticed that we have: ImageFeatures.corner_orientations .

I proposed that we add ImageFeatures.gradient_orientations function to the API which moves the following code from create_descriptor(img::AbstractArray{CT, 2}, params::HOG) where CT<:Images.NumberLike in HOG.jl into its function body:

    #compute gradient
    gx = imfilter(img, centered([-1 0 1]))
    gy = imfilter(img, centered([-1 0 1]'))
    mag = hypot.(gx, gy)
    phase = orientation.(gx, gy)

and, of course, the equivalent code for multi-channel images.

Additionally, we add an orientations2histograms or orientations_histograms (or other name) to the API where the user can specify the cell-size as well as an interpolation scheme (i.e. the current gradient weighted 'count' with trilinear_interpolation, gradient weighted 'count' with no interpolation, or a bonafide count (no gradient weighting).

The result of this function call will produce what you have called a hogmap.

The create_descriptor(img::AbstractArray{CT, 2}, params::HOG) where CT<:Images.NumberLike can then use orientations_histograms internally before constructing the canonical HOG feature using one of the specified block normalisation options.

A separate issue is adding a framework where the user can specify a region of interest in an image, as well as a window size and stride, so that the features are constructed for each window and stride inside the region of interest. We want to do this without recomputing the gradients etc. for each window inside the region of interest. I think we can handle this with the mapwindow function.

from imagefeatures.jl.

I like the approach you propose.

I am not sure about the mapwindow function. Nevertheless I think we both agree is the fact that we have to avoid RECOMPUTING the gradients in polar form and the histograms for each window of a bigger image that we take into consideration.

Then the example form the documentation that does the following:

for j in 32:10:cols-32
    for i in 64:10:rows-64
        box = img[i-63:i+64, j-31:j+32]
        descriptor[:, 1] = create_descriptor(box, HOG())
        predicted_label, s = svmpredict(model, descriptor);
   end 
end

might do something like

for j in 32:10:cols-32
    for i in 64:10:rows-64
        box = [i-63:i+64, j-31:j+32]
        descriptor[:, 1] = create_descriptor(orientation_histograms, box, HOG())
        predicted_label, s = svmpredict(model, descriptor);
   end 
end

There create_descriptor does not recompute gradients or histograms. It simply takes a slice of orientation_histograms (previously build) to generate a descriptor. The only issue I see with this approach is that the window has to move in positions that are multiples of cell_size right?

Let us consider the case that we build the orientations_histogram with cell_size=8 and then we want to take a patch that starts at position 6 of the original image. Then we "have a problem". We should restrict patches to be placed in multiples of cell_size to be able to reuse all histograms already build.

Something similar is what I did here:
https://github.com/davidbp/learn_julia/blob/master/JuliaImages/pedestrian_detection_perceptron_customhog.ipynb

And it takes 0.044186 seconds (50.51 k allocations: 8.154 MiB) (cell 58) to build orientations_histogram and apply a model over views of orientations_histogram array.

from imagefeatures.jl.