when hogs py
(get it? when pigs fly? ok then…)
histograms of oriented gradients , or HOG, are a very popular image feature in computer vision. the recipe is pretty straight forward: the image is divided into (usually 8x8) cells, for each cell you compute a (usually 9 bin) gradient orientation histogram. then there’s a funky normalization step where you group cells into blocks (typically a block is 2x2 cells or 3x3 cells), and your descriptor consists of going through each block and normalizing the histogram of each cell in that block by the block’s magnitude (i.e. each cell is represented multiple times in the final descriptor; the paper contains a much better explanation).
the other day i was looking to try out hog in python, and it turned out surprisingly difficult to find a good implementation. all in all i found two: one in opencv and another in skimage. i decided to compare the two.
first there is the issue of documentation. opencv documentation for python is…. lacking. the only way you can figure out that the HOG stuff is even accessible via python is by googling around. to figure out what the parameters were i had to glance through this code. skimage is definitely better in this department.
next i did a sanity check: i wanted to make sure the dimensionally of the output is correct for both. with the parameters i chose, i should have ended up with:
9 orientations X (4 corner blocks that get 1 normalization + 6x4 blocks on the edges that get 2 normalizations + 6x6 blocks that get 4 normalizations) = 1764.
finally, i timed these bad boys. results are below:
as you can see, the dimensionality checks out. also, looks like opencv is about 30x faster. the skimage implementation is written in pure python (i.e. not cython), so a 30x difference is about what one would expected between a python and c++ implementations.
now, are the outputs of these two implementations the same? they aren’t, and i’m not motivated enough to sift through the code and figure out what the differences are or whether one is more correct than the other :) (if you caught the sift pun, then kudos to you).
conclusion: if you are ok with no documentation, go with opencv. if you’re looking for code you can easily debug and extend, go with skimage.
 dalal and triggs: http://hal.archives-ouvertes.fr/docs/00/54/85/12/PDF/hog_cvpr2005.pdf