nessence's profile - activity

@vinayverma: This is exactly what I did. @achal: I think the comments on the bug are accurate in that this method isn't for detection.

I made some modifications which let me use the reject levels and weights but it's limited in production use until I determine how to properly combine the rejectLevels and weights with training parameters so the values are normalized. I'll eventually get these optimizations into opencv. Sponsors welcome ;)

That is correct behavior. Most of the OpenCV codebase uses Intel TBB and parallel_for() to stripe matrix operations to make use of multiple cores. Most of the algorithms for histogram of gradients can be parallelized which is why it runs so much faster.

Hello! I've worked on an implementation of this but it currently only supports GCD (macos). I have to look into how TBB is used and some other issues. Currently, if I disable TBB w/OpenCV, it doesn't use GCD. So I'm trying to find a solution that works with either before posting a patch. There's some other bugs to be fixed too :) Please see: http://code.opencv.org/issues/3147

I have multiple classifiers and some objects look similar to others, so I would like to use rejectsLevel/levelWeight values to pick the most confident result.

How can I use the numbers provided by rejectLevels and levelWeights to "reject" results, similar to how the default detectMultiScale performs rejections?

Using detectMultiScale w/rejectLevels and levelWeights isn't documented and is not as greedy with regard to rejects. In other words, when I use detectMultiScale method with rejectLevels/levelWeights, I get back a ton of results which are normally not found.

Update: After digging into the code, these values aren't usable for the objective described above. The current implementation groups pass and fail rectangles and the most pertinent class methods and members are protected and/or private.