Face Recognition – Using OpenCV with MySQL and PHP

cMySQLPHP

First of all I have asked this question on stackoverflow and got down vote for question being not belonging to the site. I am trying my luck se now(more suitable to se I guess) and I hope I will not get down vote from here too

I want to develop a face recognition app that searches the database for an image. I looked at opencv a little. I really liked it and I want to use it but the problem is I am planning to use PHP for server backend and OpenCV is in C++. My app will require lots of communication between PHP and C++ and also I will have to connect to the database and fetch images from them. Basically what I am planning to do is :

PHP will get the request which includes the desired image file
PHP will pass this image to my C++ code
C++ will search the database to find the person
C++ will pass the result to PHP
PHP will return the result to client

However this approach makes me really scared because there are lots of gray areas for me to how to do it. Should I use sockets to do the communication or IPC (POSIX Messages etc if possible) or should I use entirely C++ for my project(C++ server could be very difficult) or should I use PHP extensions(I know almost nothing about it). How can I use OpenCV with a Database and how can I perform a fast search(Hash values for grayscale cropped images maybe?). I also have to detect faces to train some images for a user which also requires the steps above. What are the suggestions you can make? Which way would be easiest for me to implement this application? Excuse me for the language and disorganized structure question but I am really worried about almost everything about the project and I really want to do it. Any guidance will be appreciated

Best Answer

There do seem to be PHP wrappers for OpenCV, such as OpenCV For PHP.

Now, for the recognition part, I think that the best way to go is to use Artificial Neural Networks. ANN's can be trained to identify people within images and are more suited because they can handle relatively inconsistent inputs and produce relatively stable results. There does seem to be ANN implementations in PHP, such as FANN. The implementation of an ANN's should also be quite fast (once trained, that is) and will remove the need for a database, unless you will be using it for other things and/or persist the neural network itself.

This would mean that you can write your solution entirely in PHP.

That being said, my experience with wrappers is that you do not always get all the goodies provided by the original library, so with that in mind, you could also opt to have PHP handle your front end and then, use C++ as back end, which should allow you to exploit all the power of OpenCV (which could come in handy for future add-ons).

As for communication between the two layers, I think using standard SOAP web service communication (for PHP and C/C++) will provide you with a robust solution.

Related Solutions

MySQL PHP – Datetime vs Timestamp in MySQL and PHP

MySQL timestamps:

Are stored in UTC

They are converted to UTC on storage and converted back to your time zone on retrieval. If you change time zone settings, the retrieved values also change.
Can be automatically initialised and updated

You can set their default value and / or auto update value to CURRENT_TIMESTAMP
Have a range of 1970-01-01 00:00:01 UTC to 2038-01-19 03:14:07 UTC

Whereas MySQL datetime:

What you store is what you get ™.
Have a range of 1000-01-01 00:00:00 to 9999-12-31 23:59:59

Values outside the range may work - but only values within the range are guaranteed to work.
You can store dates where day or month is zero.

This is the MySQL way of storing birthdays! You can't do that with a TIMESTAMP, with the only exception being the zero value of 0000-00-00.
You can store invalid dates, if you need them, in ALLOW_INVALID_DATES mode.
You can set default value to NOW() in some instances, but the preferable and more natural way of automatically initialised and updated dates is TIMESTAMP.

And of course there are also DATE and TIME, which work just like DATETIME, but of course DATE doesn't care for time and TIME doesn't care for date. All four data types work perfectly with the wide array of date and time functions, but when you are mixing data types you should be aware of conversion effects.

Now, to your question: You should use DATETIME everywhere. Not for technical reasons, but since you are still unclear on how MySQL works, DATETIME is the simpler choice. This will mean that you will have to calculate the current timestamp in PHP before storing, that's as easy as:

$mysqldate = date("Y-m-d H:i:s");

PHP's date function works like:

string date ( string $format [, int $timestamp = time() ] )

The "Y-m-d H:i:s" format is the one compatible with MySQL and by leaving the second parameter empty, date() calls time() to get the current UNIX timestamp.

Using a TIMESTAMP instead of a DATETIME has the added value of MySQL taking over the responsibility of deciding on the current timestamp, and you can skip the field when you are inserting / updating. But since you are already sending a query, and the code to get the current timestamp in PHP is minimal, you can safely go with DATETIME for everything.

As for the actual code to store the PHP timestamp into the database, you should look at PHP Data Objects, and if you are still unclear, ask on StackOverflow instead. But there are almost 1.5k related questions already, make sure you go through them before asking. Just a hint, prepared statements is how the cool kids do it.

Javascript – Prevent Click Fraud in Advertisement system with PHP and Javascript

Nobody has paid for "random advertisements" since 1998.

Serving random advertisements is a useless endeavor. How valuable are feminine product advertisements on sites aimed at men, or vice a versa. I would say they have negative value to me as an advertiser. Doing more sophisticated ad delivery implies a much more sophisticated set of metadata about the viewer, that is for all purposes anonymous unless you are Google in 2012.

PHP and RDMBS for systems like this don't scale.

See what Mochigames did for their in house custom Ad distribution server solution. hint: it isn't PHP or traditional database based.

IP Addresses aren't good for anything other than what they were designed for.

Tracking IP Addresses is the absolutely wrong way to approach this problem. IP Addresses are for routing to its location, nothing more. They are not a globally unique id, and are less than useless as such.

IP addresses aren't unique because of NAT.
IP addresses aren't unique because of spoofing.
IP addresses aren't unique because of anonymous randomizing proxies.
IP addresses are useless in detecting bot nets, the most common click fraud mechanism.
IP addresses are useless in detecting human nets as well.

Deep Pockets

Google and the other big players spend 10s of millions of dollars on this problem every year, maybe more. They can't stop it with all that money and Phd.s in pocket, I doubt some PHP and client side Javascript ( which by definition is useless ) would have any impact at all.

The only way to detect and marginalize click fraud is to apply very sophisticated machine learning algorithms ( this is where the Phd comes into play ) after the fact to look for very broad patterns of behavior ( this is where the money comes into play ) and have that algorithm adapt over time to become more accurate.

Some Click Fraud Acceptance is Inevitable

But even then you have to tune the results in favor of false negative, that is you have to be willing to accept some actual click fraud, because not paying for false positives would completely undermine your trust worthiness to your legit customers.