Posts from — November 2009

As I’ve been implementing this and actually figuring out how some of the pieces work together, it appears that variability of the data might not be as big of an issue as I thought.  I had originally assumed that the recognition algorithm would produce a single blob of data for each person you want to recognize, and that you’d be matching against that.  Now that I look at it, that doesn’t seem to be the case.  Instead, it looks like it chops each training image down to some constituent particles, then you run through these particles to determine which one is the closest to the image you want to match.  Which means that hopefully variability won’t be a huge problem, since I’m matching to an individual image.

Then again, I’m talking about the 2500-dimension eigenvalue PCA subspace or something like that, so I really have absolutely no idea what I’m talking about.

Eigenvector eigenvector eigenvector eigenvector eigenvector.

Creepy.

And a sign that this isn’t going to work so well.  I think at this phase, you’re supposed to see something that, well, kinda looks more like a face.

It’s 4 PM and this is all I have so far.  This sucks.

For those playing the home game, here’s some of the sites with examples that I’ve been using:

OpenCV Face Detection: http://nashruddin.com/OpenCV_Face_Detection  This brief post shows how to use the Face Detection stuff in OpenCV.  It’s a bit clearer than the example on the OpenCV site.

Implementing Eigenface:  http://www.cognotics.com/opencv/servo_2007_series/part_5/index.html  This is a detailed article on recognizing faces using OpenCV, including explaining how some of the algorithms work.  Some of the information here is what makes me think that my initial stab at recognition is doomed to failure.

And, of course:

OpenCV: http://opencv.willowgarage.com/wiki/Welcome

OpenCVSharp: http://code.google.com/p/opencvsharp/

I got some information that might explain what was going on with all those OpenCV errors.  Apparently the version of the DLLs installed with the Windows Binaries package for OpenCV 2.0 aren’t exactly the Windows versions of the binaries.  They’re MinGW compiled libraries, and therefore might have a few slight incompatibilities with the OpenCVSharp package.

In order to get a version that, you know, works, I’m going to have to compile it myself using CMake.

No.  No no no.

THIS IS WHY I DON’T USE LINUX.  I like my software pre-compiled and working.  I don’t like spending hours tracking down dependencies that I shouldn’t even care about.

Go to hell, Richard Stallman.  This is all your fault.

When I buy a pizza, I don’t have to put the sauce, cheese and toppings together myself.

When I buy a book, I don’t have to arrange the pages on my own.

When I buy a car, I don’t have to collect various tools and assemble it.

Can you imagine the collective cries of anguish if people who bought Call of Duty: Modern Warfare 2 a couple of weeks ago had to ./configure, make, make install before playing?

Most people can’t even us

FATAL ERROR
'/usr/home/cwp2/complaint.so': Compile Failed:  Requires GLIBC >= 2.0.6-i386

Here’s the average image that came out of CvCalcEigenObjects: .

No, really, that’s what it was.  There’s something there.  Sort of.  A 50×50 white square.

Hmmm…  I think I need to work on this some more…

Turns out the version of the 1.1pre1a OpenCvSharp library that I pulled down as part of the source was newer than the one I got in September, and it already had the CalcEigenObjects function in it.  So, I didn’t have to go all Kobayashi Maru on the thing and produce a hacked-up Frankenassembly after all.  (Which, in a way, is somewhat disappointing…)

And remarkably enough, I run the old stuff and the new stuff and it doesn’t die left and right.

Of course, I have no idea what it’s doing, but using a lot of CPU and not crashing makes it seem like it’s doing something right.  At least it’s a step in the right direction.

I went back to the code I wrote yesterday that was working with 1.1pre1a yesterday and now it’s giving access violations.  So something in 2.0 is very unhappy.

I am very unhappy, too.

Let’s see…  I can go back to 1.1pre1a and not be able to use the functions I need to recognize faces, or I can keep on 2.0 and do NOTHING AT ALL.

I get the sense that, much like the Higgs Boson and the LHC, my program is sending itself back in time in order to prevent itself from being written, because the consequences of having a program that can automatically wipe out Wesley Crusher from TNG episodes are too disastrous to allow to happen.

However, there is a third path, a way to solve this no-win situation.  In order to fix the first bug I ran into with 2.0, the P/Invoke thing, I had to get the source for OpenCVSharp.  At the time, I was slightly annoyed that it was pulling down both the 2.0 and 1.1pre1a branches from the repo.  However, now that I have the source to 1.1pre1a and the source to 2.0, why not pull the missing code out of the 2.0 branch, stick it in the 1.1pre1a branch, and go from there?

You can always find a solution by reprogramming the problem.

OpenCV 2.0 seems to be a big bunch of access violations.  I can’t even get some of the basic operations like resizing or converting to grayscale working.  Stuff that I’ve done before and that should work.

This day has not been productive.

I had to change the filename references in the OpenCvSharp source file CvInvoke.cs.

[cc_csharp]
#region DLL File Name
public const string DllCxcore = “libcxcore200”;
public const string DllCV = “libcv200”;
public const string DllHighgui = “libhighgui200”;
public const string DllCvaux = “libcvaux200”;
#endregion
[/cc_sharp]

Now I’m getting an access violation somewhere, so I think that part worked.