[Bug 678485] opencv templatematch element improvements

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=678485
  GStreamer | gst-plugins-bad | 0.10.x

--- Comment #3 from wackywim <gnome at williammanley.net> 2012-06-20 15:39:48 UTC ---
Created an attachment (id=216846)
 View: https://bugzilla.gnome.org/attachment.cgi?id=216846
 Review: https://bugzilla.gnome.org/review?bug=678485&attachment=216846

Set caps to BGR order

templatematch operates on BGR data. In fact, OpenCV's IplImage always
stores color image data in BGR order -- this isn't documented at all in
the OpenCV source code, but there are hints around the web (see for
example
http://www.cs.iit.edu/~agam/cs512/lect-notes/opencv-intro/opencv-intro.html#SECTION00041000000000000000
and http://www.comp.leeds.ac.uk/vision/opencv/iplimage.html ).

gst_templatematch_load_template loads the template (the image to find)
from disk using OpenCV's cvLoadImage, so it is stored in an IplImage in
BGR order. But in gst_templatematch_chain, no OpenCV conversion
functions are used: the imageData pointer of the IplImage for the video
frame (the image to search in) is just set to point to the raw buffer
data. Without this fix, that raw data is in RGB order, so the call to
cvMatchTemplate ends up comparing the template's Blue channel against
the frame's Red channel, producing very poor results.

The BGR order probably needs to be applied to the other opencv elements
too, but we haven't had time to confirm that.

This patch includes a test that a template will match against itself
which will be run with `make check`

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.