HOGFeatures function

[egorovp]

Problem

1. Why the third features' dimension aren't the same in CTS and in documentation? (therefore, the further formation of the output tensor is incorrect)

   e.g. in CTS for the size of the third features' dimension it's not enough multiplication by (cells_per_block_w * cells_per_block_h)

2. In CTS TEST(HogFeatures, testNodeCreation): why bins_dims is passed instead of features' dimensions?

Links

1. Standard
2. Conformance Tests

[fbrill3]

@egorovp, the best folks to look at these issues were on spring break last week, but will review them soon and get back to you.

[fbrill3]

Here is some feedback on each of your two questions from one of our group members:

1. Yes, the third dimension mentioned in the spec is not same as used in CTS. Need further check as to what is the correct way to implement or specify this and rectify spec/CTS.
2. Looks like a bug in CTS. Need to check the sample implementation as well.
   HOG Feature descriptor dimension can be calculated by multiplying bins_dims by number of cells per block. For a square block and cell the number of cells per block will be either (block_width/cell_width)*2 or (block_height/cell_height)*2. Note that the spec states that the blocks are square grids and the third dimension specified in the equation gives the feature descriptor output size.

[egorovp]

@fbrill3, thank you for your responses. Looking forward to update

[kiritigowda]

Thank you for raising this. The OpenVX specification is the source of truth. The third dimension of the vxHOGFeaturesNode output tensor is correctly defined in the spec as:

⌊(W_w - B_w) / B_s + 1⌋ × ⌊(W_h - B_h) / B_s + 1⌋ × ((B_w × B_h) / (C_w × C_h)) × num_bins

The (cells_per_block_w × cells_per_block_h) factor is required and the CTS is missing it. Additionally, the use of bins_dims instead of features dimensions in testNodeCreation is also a CTS bug.

Both issues will be fixed in the 1.3.2 CTS release. A CTS tracking issue has been filed: KhronosGroup/OpenVX-cts#32

The specification is correct as written — no documentation changes required.