Ask Your Question

Aenimated's profile - activity

2016-01-13 12:44:05 -0600 answered a question Is ICR (Intelligent character Recognition ) is possible using opencv 2.*

Hi Santhosh,

OpenCV 2.4 has some machine learning facilities that might support ICR, but in my experience, it's a bit limited. Getting good results from an ICR system is likely to require a fairly sophisticated neural net (a good choice might be a deep convolutional neural net trained on a very large training set) and ideally, you'd want to leverage higher-level constructs like words or even sentences using something like a Hidden Markov Model for example to compensate for the inevitable error/loss inherent in any neural net tasked with such a complex problem.

I would recommend looking into other machine learning libraries, and use OpenCV for the more basic image processing. I'm currently using Google's recently released TensorFlow API, but that's currently limited to Linux support, and the full API is only supported in Python, so you may want to research the various alternatives before making a decision.

Hope that helps.

2016-01-12 15:17:55 -0600 commented question Generating matrix representing nearness to edges

Wow, distanceTransform() looks to be exactly what I'm looking for! I'll need to do a little pre- and post-processing I think, but it looks doable. Thanks for the suggestion!

2016-01-12 13:38:06 -0600 commented question Generating matrix representing nearness to edges

Thanks for the quick response, LorenaGdl. I'm thinking I probably won't take that approach though - I'm not sure that I could make it efficient enough for my purposes. It seems like I'd need to build a full list of contours and test each pixel against the whole list. It's certainly possible that there is no good "out-of-the-box" solution for this, so I'm prepared to build my own algorithm if need be. :)

2016-01-12 13:03:36 -0600 asked a question Generating matrix representing nearness to edges

Hi Community!

I'm attempting to improve a hand segmentation algorithm I'm working on, and as an experiment, I'd like to give higher priority to pixels that are near an edge. (My most typical failure case is caused by walls that are similarly colored as skin, but walls often have very few edges compared to hands.)

Anyway, I was getting ready to build a custom algorithm for this, but I can't help but think OpenCV probably has image processing functionality for this. Here's what I want to do: Given a binary image generated by Canny(), I want to produce a matrix of the same size, with floating point values normalized from 0.0 to 1.0, with 1.0 representing an edge pixel, 0.0 representing a pixel that is some fairly large distance from any edge pixels, and intermediate values following a curve, with the value dropping more rapidly the further the pixel is from an edge.

This sounds an awful lot like a Gaussian filter, but there are a couple issues I have with that. First, I'm looking to have some non-zero values for pixels that are pretty far from an edge, so the kernel would have to be very large - hence, very poor performance. Second, running something like GaussianBlur would probably need further post-processing to normalize the results to 0.0 to 1.0.

Ideally, a custom implementation could scan through each pixel, iteratively spiraling out until it finds an edge pixel - my guess is that such a solution would be much more efficient than using convolutional approaches since it can stop once it finds a single edge pixel.

Anyway, before I spend effort implementing this in C++ (and then converting to Python as well - long story), is there a better, efficient approach to do what I'm trying to do provided (or supported) by OpenCV?

Thanks!

2016-01-11 20:52:18 -0600 answered a question What is the best method for getting ROI of an eye?

I'm working on a (somewhat) related problem and thought I'd offer a suggestion based on my own work. I haven't used the face detection sample, but I assume it uses a cascade classifier. That's a great solution for finding a face, or eyes, or (in my case) a hand, assuming the classifier was trained on robust data including a large variety of images of the object from various angles, lighting conditions, etc. So first off, if you want to detect eyes, and you have some particular angles that are giving you trouble, you could work on training your own cascade classifier that's better suited for your application.

Another thing to note wrt moving images, once you know where an eye is, it typically doesn't move very far from frame to frame. So if you're looking to track eyes in a video for example, you may get better results by using the cascade classifier only as the first phase, and then tracking it from that point onward using an alternate approach. In my case, I find the hand using a cascade classifier, then I basically monitor a loose bounding box, updating it each frame to keep the hand inside the box.

Just some ideas to consider.

2016-01-11 20:52:17 -0600 answered a question Enable Auto Exposure using code

I know this is a very old post, but just in case other stumble upon it, let me offer the solution I used. First of all, I'm using OpenCV 2.4.11. At least in that version, the CV_CAP_PROP_AUTO_EXPOSURE is not implemented. However, it turns out that the logic that handles setting CV_CAP_PROP_EXPOSURE (at least the DirectShow-based interface used for Windows) already has the hooks necessary to restore the default values for the exposure setting.

The code is found the opencv\sources\modules\highgui\src\cap_dshow.cpp in the videoInput::setVideoSettingCamera function. I added the following code as a quick and dirty solution for restoring auto-exposure functionality:

if ( (Property == CameraControl_Exposure) && (lValue == 0.0) ) useDefaultValue = true;

Then rebuild the highgui library and use the modified copy. This allows you to restore the auto-exposure using cap.set(CV_CAP_PROP_EXPOSURE, 0.0) in your code. Of course, really you ought to implement CV_CAP_PROP_AUTO_EXPOSURE for a proper solution, but this has worked well for my purposes.

Hope this helps someone.