If old opencv1-style legacy include directory is available,
this change becomes purely cosmetic (maybe will compile a bit faster).
It becomes an FTBFS fix when opencv1-style include directory is missing
(possibly because opencv package maintainer decided not to pack it).
https://bugzilla.gnome.org/show_bug.cgi?id=747705
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.
Previously changing the template property resulted in an exception
thrown from cvMatchTemplate, because "dist_image" (the intermediate
match-certainty-distribution) was the wrong size (because the
template image size had changed).
Locking has also been added to allow changing the properties (e.g. the
pattern to match) while the pipeline is playing.
* gst_element_post_message is moved outside of the lock, because it will
call into arbitrary user code (otherwise, if that user code calls into
gst_templatematch_set_property on this same thread it would deadlock).
* gst_template_match_load_template: If we fail to load the new template
we still unload the previous template, so this element becomes a no-op
in the pipeline. The alternative would be to keep the previous template;
I believe unloading the previous template is a better choice, because it
is consistent with the state this element would be in if it fails to
load the very first template at start-up.
Thanks to Will Manley for the bulk of this work; any errors are probably
mine.
The early return was bypassing the call to gst_pad_push. With no
filter->template (and thus no filter->cvTemplateImage) the rest of this
function is essentially a no-op (except for the call to gst_pad_push).
This (plus the previous commit) allows templatematch to be
enabled/disabled without removing it entirely from the pipeline, by
setting/unsetting the template property.
Some elements had vague caps, such as "video/x-raw-rgb", which caused problems
at least with textwrite. For other elements, the underlying OpenCV functions
support more than just one image type, so I increased the number of supported
caps.
I created a utility function "gst_opencv_caps_from_cv_image_type", so each
element creates caps directly from OpenCV image types, such as CV_8UC1 for
8-bit grayscale. This function uses gstvideo to create uniform caps.
https://bugzilla.gnome.org/show_bug.cgi?id=635304
