Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Face recognition. Are there any VFP utilities or advancements made in this direction by anyone?
- Thread starter dkean4
- Start date
Dan Freeman
Programmer
I haven't heard of anything. Have you tried The Google?
- Thread starter
- #3
Mike Lewis
Programmer
On the contrary. I just did a similar search and saw several sites offering components, APIs, SDKs, or similar.
Perhaps your mistake is in looking for products that specifically offer Visual FoxPro support. These days, very few software vendors have even heard of VFP, much less going out of their way to support it. You would do better if you look for a generic tool that can be used with any programming language, and then figure out how to use ith wit VFP.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Olaf Doschke
Programmer
I second Mike.
First, let's face VFP itself wouldn't be a candidate to do image processing like face recognition in itself. I expect that to be done with a neural network and that's not a core feature of VFP. Candidate languages for implementation of such a thing are rather lower level languages like C/C++ and some core of it perhaps using graphics card hardware acceleration or assembly. People might also do this in Java and C#, but GDIplusX capabilities or the GetPixel API call surely isn't a base to consider processing images for face recognition on a pixel by pixel basis.
Now let's consider a ready to use module built in any programming language. The module itself would take the input of a camera or image file and do the face recognition, and then rather return what person was detected or perhaps a list with some confidence value in percentage from 0 to 100% for a list of candidate persons. The persons have to be learned somehow, so it will have its own database of some kind, but I'd not expect a classical RDBMS relational database. If you ask the module, whether a certain person matches the video/picture, it should rather answer with a boolean .T./.F. (1/0) or a confidence value and everything else should be self-contained.
Such small interface should be easy to connect to VFP, even though you don't find something including straight VFP integration, you'll find something with any integration, as such a module wouldn't make sese without any API or SDK. I'D expect samples for C++ or C# or any other binding and then you nowadays should be able to talk any such second language aside of VFP and do that final last step to forward that boolean or confidence percentage to VFP yourself.
Don't expect anyone to do libraries for VFP, look out what you can bind to and you should have that base knowledge about VFP interop possibilities:
You can use DECLARE to declare stdcall functions in "classic" functional DLLs or you can use ActiveX DLLs or OCXes. One more possibility MS gave us is creating and consuming FLLs, but such libraries are intended for VFP and I don't see anyone making such anymore, it has a very limited target group of VFP developers. You could easily turn almost any stdcall DLL library into an FLL, it just needs a little extra structural info, but it's not worth the hassle, as you can already bind to such a DLL via DECLARE. FLLs only really make sense, if the FLL also makes use of being more directly integrated into the VFP process and having access to VFPs internals like Nametable (variables), but again: Who would create something only usable for VFP?
Rick Strahl added another extension vector with his DotNet Bridge. It essentially creates COM interop info of Assembly DLLs on the fly, even if they were not compiled for interop. In that regard, it's making use of the COM interoperability of VFP.
And then, finally there are simple interfaces like calling an EXE with command line parameters and interfacing via result files. Interprocess Communication is not that simple, but also has some limited use and then there are webservices or Rest APIs, all the stuff that is remote and not involved with the VFP process itself can be used, too, as the interfaces to these are RAM, file system, http or other web protocols.
Anyway, integrating such a thing into a VFP application is a bit like forcing an air condition or parking sensor into an oldtimer. You surely have it easier to do such things in separate new projects done in anything but VFP.
Bye, Olaf.
First, let's face VFP itself wouldn't be a candidate to do image processing like face recognition in itself. I expect that to be done with a neural network and that's not a core feature of VFP. Candidate languages for implementation of such a thing are rather lower level languages like C/C++ and some core of it perhaps using graphics card hardware acceleration or assembly. People might also do this in Java and C#, but GDIplusX capabilities or the GetPixel API call surely isn't a base to consider processing images for face recognition on a pixel by pixel basis.
Now let's consider a ready to use module built in any programming language. The module itself would take the input of a camera or image file and do the face recognition, and then rather return what person was detected or perhaps a list with some confidence value in percentage from 0 to 100% for a list of candidate persons. The persons have to be learned somehow, so it will have its own database of some kind, but I'd not expect a classical RDBMS relational database. If you ask the module, whether a certain person matches the video/picture, it should rather answer with a boolean .T./.F. (1/0) or a confidence value and everything else should be self-contained.
Such small interface should be easy to connect to VFP, even though you don't find something including straight VFP integration, you'll find something with any integration, as such a module wouldn't make sese without any API or SDK. I'D expect samples for C++ or C# or any other binding and then you nowadays should be able to talk any such second language aside of VFP and do that final last step to forward that boolean or confidence percentage to VFP yourself.
Don't expect anyone to do libraries for VFP, look out what you can bind to and you should have that base knowledge about VFP interop possibilities:
You can use DECLARE to declare stdcall functions in "classic" functional DLLs or you can use ActiveX DLLs or OCXes. One more possibility MS gave us is creating and consuming FLLs, but such libraries are intended for VFP and I don't see anyone making such anymore, it has a very limited target group of VFP developers. You could easily turn almost any stdcall DLL library into an FLL, it just needs a little extra structural info, but it's not worth the hassle, as you can already bind to such a DLL via DECLARE. FLLs only really make sense, if the FLL also makes use of being more directly integrated into the VFP process and having access to VFPs internals like Nametable (variables), but again: Who would create something only usable for VFP?
Rick Strahl added another extension vector with his DotNet Bridge. It essentially creates COM interop info of Assembly DLLs on the fly, even if they were not compiled for interop. In that regard, it's making use of the COM interoperability of VFP.
And then, finally there are simple interfaces like calling an EXE with command line parameters and interfacing via result files. Interprocess Communication is not that simple, but also has some limited use and then there are webservices or Rest APIs, all the stuff that is remote and not involved with the VFP process itself can be used, too, as the interfaces to these are RAM, file system, http or other web protocols.
Anyway, integrating such a thing into a VFP application is a bit like forcing an air condition or parking sensor into an oldtimer. You surely have it easier to do such things in separate new projects done in anything but VFP.
Bye, Olaf.
- Thread starter
- #6
Ha ha ha... Thanks guys. I come from the world of Digital Design and zoom/correlation/rotation of images is something I am intimately familiar with. Years ago I was working on a surveillance stereo vision using VFP, to locate moving objects on orthogonal planes. It is mostly mathematics, matrices etc. With low res images it is possible to keep up, up to some point. That was in the early 90's. The LOAD command of FoxPro provided a hook to Assembly calls... very involved, but I used it effectively.
With today's processors, however, VFP has enough muscle to pipe image pairs to an outside EXE and receive replies from the external app at a nice and slow 10 FPS. And that is way more than what is needed to do face recognition. The biggest problem is getting an clean or homogeneous background so you can register the relative centers of the faces, by a single boundary approximation.
Both of you are correct about not lifting the weight inside VFP. I appreciate your advice as always with great regard. It is nice to be a member of this forum. Like you I am aware of this, but my question was not specific enough. I apologize for that.
Maybe I should have asked if you know any OCXs meant to do recognition. And I promise to be more specific next time.
With regards,
Dennis Kean...
With today's processors, however, VFP has enough muscle to pipe image pairs to an outside EXE and receive replies from the external app at a nice and slow 10 FPS. And that is way more than what is needed to do face recognition. The biggest problem is getting an clean or homogeneous background so you can register the relative centers of the faces, by a single boundary approximation.
Both of you are correct about not lifting the weight inside VFP. I appreciate your advice as always with great regard. It is nice to be a member of this forum. Like you I am aware of this, but my question was not specific enough. I apologize for that.
Maybe I should have asked if you know any OCXs meant to do recognition. And I promise to be more specific next time.
With regards,
Dennis Kean...
Olaf Doschke
Programmer
Well, you asked for VFP utilities or advancements and even if you expect someone to have used an OCX, well, that's not the core usage of VFP, is it?
What I meant to point to meantioning all the extension vectors you have with VFP is, you should simply concentrate to find what you need in terms of face recognition and can integrate many things directly or if that fail using any of the extensibility features of VFP simply do it in another language.
If you lack a bit C++ knopwledge really take a "for dummies" or "in 21 days" books, those are having 21 lessons you can also do in less days. It's worth to know what pointers are and how this translates to VFP by reference parameters, it's worth to look into C structs and know you can compose them into VFP strings and use BINTOC() and CTOBIN() to create the string parts or read 4 string bytes out to their corresponding numeric values. It's worth to know data types can be stored in least significant byte first or last order. And these are already very detailed things to know to be able to know what DECLARE you need, given a description like MSDN has or like c++ header files contain as function declaration.
You're doing very high level stuff, so you should be able to do all this, you're far less in need of help, if you simply help yourself, you have enough base knowledge to build up upon and development is not a side
topic to you.
Bye, Olaf.
What I meant to point to meantioning all the extension vectors you have with VFP is, you should simply concentrate to find what you need in terms of face recognition and can integrate many things directly or if that fail using any of the extensibility features of VFP simply do it in another language.
If you lack a bit C++ knopwledge really take a "for dummies" or "in 21 days" books, those are having 21 lessons you can also do in less days. It's worth to know what pointers are and how this translates to VFP by reference parameters, it's worth to look into C structs and know you can compose them into VFP strings and use BINTOC() and CTOBIN() to create the string parts or read 4 string bytes out to their corresponding numeric values. It's worth to know data types can be stored in least significant byte first or last order. And these are already very detailed things to know to be able to know what DECLARE you need, given a description like MSDN has or like c++ header files contain as function declaration.
You're doing very high level stuff, so you should be able to do all this, you're far less in need of help, if you simply help yourself, you have enough base knowledge to build up upon and development is not a side
topic to you.
Bye, Olaf.
- Thread starter
- #8
Olaf,
I am not asking any of you to improvise and work out the solutions for me. I will gladly do the heavy lifting. However, I am trying to figure out if there is a simpler solution than starting from scratch, Olaf. Why reinvent the wheel? And I have been away from VFP way too long to know where VFP + extensions have gone over the years. Your suggestion is clearly inevitable. I just wanted to figure out if someone had solved that problem before in some way.
So, I will take up some C++, as per your advice. In fact I have done some wild graphics in the late 80's with C, (not C++)... 3D Mandelbroth and many other abstruse topics. But you and I know well that, with C...C++ alone, solutions take far longer. I love the combination of VFP with whatever else, C++, or any other protocol, language etc can accomplish. Here is something you may want to know, VFP is very fast in rotating huge matrices like 256x256, with arrays. From my experiments it is faster than Excel. So, I have a lot of reasons to suspect that folks may have solved some of these problems with VFP.
As always, you are an eye opener to me. My problem, presently is that I have done lots of web development crap. I detest web development, a disorganized pot pourri of mindless hackers. I have not kept up with VFP, like you and others on this forum. And I am familiar with many of the API's, which I learned in the past from the VFP solution examples. But occasionally I step on a major disconnect. So, as usual, I will take your advice. Thanks for your advice again.
Dennis
I am not asking any of you to improvise and work out the solutions for me. I will gladly do the heavy lifting. However, I am trying to figure out if there is a simpler solution than starting from scratch, Olaf. Why reinvent the wheel? And I have been away from VFP way too long to know where VFP + extensions have gone over the years. Your suggestion is clearly inevitable. I just wanted to figure out if someone had solved that problem before in some way.
So, I will take up some C++, as per your advice. In fact I have done some wild graphics in the late 80's with C, (not C++)... 3D Mandelbroth and many other abstruse topics. But you and I know well that, with C...C++ alone, solutions take far longer. I love the combination of VFP with whatever else, C++, or any other protocol, language etc can accomplish. Here is something you may want to know, VFP is very fast in rotating huge matrices like 256x256, with arrays. From my experiments it is faster than Excel. So, I have a lot of reasons to suspect that folks may have solved some of these problems with VFP.
As always, you are an eye opener to me. My problem, presently is that I have done lots of web development crap. I detest web development, a disorganized pot pourri of mindless hackers. I have not kept up with VFP, like you and others on this forum. And I am familiar with many of the API's, which I learned in the past from the VFP solution examples. But occasionally I step on a major disconnect. So, as usual, I will take your advice. Thanks for your advice again.
Dennis
Olaf Doschke
Programmer
Just to state it clearly: I don't suggest you start face recognition from scratch, just integrating any face recognition into VFP in any of the extension vectors VFP gives you directly or indirectly, by writing a wrapper around the few interface methods/functions whatever of a face recognition suite. Then you are not at all limited on what you choose, it doesn't need to be OCX just to be VFP friendly, if you can't import or use it in VFP directly you can write a wrapper to it, that could for example be used by DECLARE, as ActiveX or via .NET Bridge.
So whatever you find, it's even simpler, if you find something explaining usage in C# or C++, then your only work is writing a wrapper in that language to open up a way for VFP to act on this. The job of such a wrapper is no more and no less than to forward a call from VFP to the face recognition module and pass the answer back. It merely exists to be able to hook into this, if there is no direct way from VFP. One good example is VFPs inability to handle arrays as COM parameters, sometimes it's simpler to let VB do this and VFP merely send in a comma separated values string or XML the VB transforms to a COM array. One other reason is structs are heavily used, that can also be simpler done in C++ and if there is a C# interface it's a good candidate for using the .NET bridge to make use of the interface classes or a wrapper you write more VFP friendly.
Bye, Olaf.
So whatever you find, it's even simpler, if you find something explaining usage in C# or C++, then your only work is writing a wrapper in that language to open up a way for VFP to act on this. The job of such a wrapper is no more and no less than to forward a call from VFP to the face recognition module and pass the answer back. It merely exists to be able to hook into this, if there is no direct way from VFP. One good example is VFPs inability to handle arrays as COM parameters, sometimes it's simpler to let VB do this and VFP merely send in a comma separated values string or XML the VB transforms to a COM array. One other reason is structs are heavily used, that can also be simpler done in C++ and if there is a C# interface it's a good candidate for using the .NET bridge to make use of the interface classes or a wrapper you write more VFP friendly.
Bye, Olaf.
- Thread starter
- #10
Olaf,
That much is clear. And that is exactly the path I am on. The trouble, as always, is to start with something which has been deemed worthy of messing with. That was the nature of my questions. How many times have you implemented some ActiveX, which later you found was way too retarded? Well that happens to me a lot. Just trying to save time, my good friend. And thank you so much for all your help.
That much is clear. And that is exactly the path I am on. The trouble, as always, is to start with something which has been deemed worthy of messing with. That was the nature of my questions. How many times have you implemented some ActiveX, which later you found was way too retarded? Well that happens to me a lot. Just trying to save time, my good friend. And thank you so much for all your help.
Olaf Doschke
Programmer
On that aspect I suggest you better don't ask the VFP community or any database developers, ask another community, eg around the topic or business of security what face recognition software/framework/module/suite or even hardware is state of the art. If they offer an ActiveX that works in VB or VB.NET or C#, then you don't need to care, whether it's "ratarded" in VFP. VFP isn't the first class end user for this, but you can always wrap things, even retarded ActiveX can be used with a new onionlayer wrapper around them specificially adapted to what VFP types VFP can handle.
Bye, Olaf.
Bye, Olaf.
- Status
Similar threads
- Locked
- Question