I am planning to verify the user input for my application using the biometric input. I did some research on net and came up with following options of biometric input:
Fingerprint
Facial Recognition
Retinal Scan
Iris Scan
Voice Recognition
Signature Verification
Out of which I felt the fingerprint as most suitable options. But the problem with this is the API of the fingerprint device will vary with its hardware. So most probably I think I will need to code against the multiple devices API, which I don't find friendly.
I intend to do the programming stuffs in C#. Is there any way out of this. As I am new to this I'm clueless. What is the way to attack this problem and how vast is the project scope and what should be my approach for this project.
The problem is not unique to fingerprint readers, it will apply to all other options in your list and many other peripherals. In fact a standard API is the exception.
So you will have to look for somebody selling a library for this or writing your own (COM and/or Interop). And rolling your own will usually not be small or simple project.
Your program will have a list of supported devices, excluding the rest.
A colleague of mine was tasked with building a biometric based staff clock-in system for the company we both worked for. We, IT, choose Fingerprints as the biometric source. He researched and used this library from Bayometric - Griaule Fingerprint SDK along with some cheap MS print readers. From what he showed me and talked about at the time, does lead me to believe that this .net library had a nice API and was easy to work with.
The biometric system is still being used today, some 5 years later.
I work in the biometric field, and I use C# for a lot of the fingerprint stuff I do. My company had to develop a fingerprint device abstraction library for this very reason. Consider that all fingerprint scanners only REALLY need one call: getImage. Knowing this, my company wrote a library which initializes and sets up each device, creates a generic wrapper, assigns a unique ID, and throws it into a big list that you can enumerate over.
Then from the C# side all you have to do is "pick" a device (all you have to go on is a unique ID and maybe a manufacturer) and then use it. The image data that comes back has to be decided on in advance so that you know what you're going to get every time
The main problem with this approach is that a lot of devices these days have various gimmicks (e.g. programmable flashing lights), and by abstracting the devices away you lost the ability to access these special abilities. Furthermore, some devices actually return multiple channels of data (various spectrums of light for example) and you have to throw away all but one channel so that the application can remain device agnostic, which is a hard decision.
Finally keep this in mind: if you do minutiae extraction, the device you use unfortunately WILL impact which minutiae are detected. Some devices are "tuned" for certain algorithms, and so enrolling with device A and matching with device B may not work at all despite having picture-perfect fingerprints.
There is a similar question here: finger print reader for .net windows forms / WPF or silverlight client
Check the links in the answers
Related
I happen to have an old RFID reader from Touchatag. It's pretty old already but it seems to work fine. Unfortunately, Touchatag has stopped their support for this device and besides, it required an internet connection which doesn't make it a very practical solution...
What I would like to do is to use this device without the need for an internet connection and inside an application that's written in C#. Don't know what this app is going to do, but right now I'm investigating all the options that are available for this device. So, does anyone know a good C# library and other sources that allow me to use this device?
(Btw, this is purely experimental.)
I don't know of any C# libraries of hand, but you can check out either:
IOTOPE
Java project that includes a low level library and a more high-level interface to the reader. You can probably adapt it to provide an interface to your C# application.
See http://blog.iotope.com/node/quick-starter/
libnfc
Low level NFC library. Mostly targeted for unix like systems, but could be put to work on windows as well.
See https://code.google.com/p/libnfc/
If you're experimenting with RFID, rather than works the bugs out of interfacing with a custom reader, you can buy a cheap USB RFID reader for around 10 £/$/€
A lot of them simply act like a keyboard and 'type' characters into your application (some even add a carriage return which is handy)
My project
I am working on a small program which has to set an alarm if the user locks the computer without removing the Smart Card from the computer.
I am using C# with WPF and .Net 4.0 and my smartcard is version V4.2C
My problem
I have all the functionality to work but I simply don't know how to detect if the Smart Card is in the Smart Card Reader.
I have tried to search on google but with no result so I hope some of you can help me.
Usually you would want to use the PC/SC framework for talking with a smart card, but it can be quite some work to implement from scratch yourself.
I would recommend to look into some existing project and get some ideas from there, as there are many projects that implements PC/SC in .NET.
Take this one from CodeProject for example.
Well, if I google for "C# smartcard" the first link which pops up is a code project article. It appears that the project provides events for detection of smartcard insertion/removal which is probably what you want.
Have a look at http://code.google.com/p/pcsc-sharp/
Works very well for me on 32bit and 64bit platforms, and supports mono too.
Besides the use of PC/SC to detect the presence of the card , from your description that doesn't seem very secure if the presence of the card in the reader is the sole condition for (un?)locking the PC without alarm, unless you scan periodically the card for some randomly generated data or some similar process which would ensure that the card isn't present since onbly the card could generate the right random sequence?
I have been assigned to know to how to make a GPS Navigation Software for Win CE 6.0 operating system. But after searching a lot, I couldn't find a good way to start.
I have downloaded some free software by which i can view the provided ShapeFile files but I want to make a software by which I can view those files in my customized mode.
My preferred technology is .NET 3.5 / 4 and my OS supports silverlight.
You can visit this link what exactly I want to do.
Thanks in advance.
I have to work on a predefined data set (shape files) provided by my client and i have to put my app in GlobalSat [GA-5718] device.
Your suggestions are very fine but it won't work for me. Thats why I am in a confusing position.
At first you'll need to get access to the GPS data and read it. Most GPS modules act as a serial device on some COM port and provide their information in the NMEA Standard.
To get this easily read you should take a look at the OpenNETCF Serial Library, cause it provides an easy access to the informations and is able to read the NMEA strings.
But most GPS modems needed to be initialized by sending a correct NMEA input string. For these you should take a look into this documentation, this site or in the comment in the source above function public bool SendGpsMessage(string GPSSentence).
With these informations you should have a good starting point to correct read in the GPS data. Visualization of these informations to the user (like showing a Map with the current position) is another task. But maps.google.com API would be a possible candidate if you software runs on a machine with internet connection and you don't mind the costs for this connection.
The fact that you are asking this question strongly suggests you do not have the resources or ability to write it from scratch (it is a substantial project). Therefore you will have to use existing toolkits. You mention Silverlight, so I suspect you are going to be working in an online environment. Therefore I would recommend the Bing Maps Silverlight Control. IMHO, this outperforms the Google Maps control at the moment - but it is a moving target. This is a place where active competition results in two products (Google Maps & Bing Maps) constantly trying to out do each other.
If this is for a commercial application, then check the EULAs for these services - although many enthusiasts assume they are free, this is not necessarily the case. Most commercial applications cost significant sums ($1000s per month). In such a situation, the choice of service will probably come down to cost rather than technology.
I am trying to design a new application which basically aims at providing biometric authentication services. What I want to do is that the app will present the user with an interface where the user can get his eye scanned for authentication. The most important feature I want to incorporate is that the user need not have a webcam, the app must be able to read the eye from the display device i.e. CRT or LCD screen itself.
I want info about the best framework available for this. Once successfully tested, I am planning to provide it as a webservice. Any one who will help me will get a royalty from my income.
I think you're want Microsofts new multi-eye monitors. This is a special version of Multi-Touch intended for eye validation, much like how Microsoft Surface is intended for surface finger interaction. For example, you can just lay an eye on the table, and the table can sense the eye is there and validate it, using blue-tooth or whatever. I saw a demo where this guy just shakes his eye near the table and it validated him. I was so cool. SDK's will be available for Retina, Iris, etc.
I know for a fact that there has not been a lot of work done in this area, but the potential is big. I wish you luck.
The best way to do this is to use (old) monitors with electron tubes (LCD screens are not suited for your purpose). By applying a rectifier for the electric current input, swapping the polarity of the cable set to the electron tube and focussing the electron ray to a radio button on your user interface where the user is required to stare at you can make sure that the ray hits directly his eye and is reflected back to a small canvas you need on your UI (users should look a bit cross-eyed for this purpose). The electron pressure paints the retina layout directly to the canvas and you can read it out as a simple bitmap. No special SDK required.
You might try Apple's new iEye. This fantastic, magical add-on to the iPad rests on the eye, and is operated via a single easy-to-use button at the bottom of the device. Unfortunately, it only works with the iPad, and the SDK is proprietary.
I don't get you.
How do you propose the image of the eye is collected without some kind of image capture device.
A bog standard 'display device' is an 'output device' as opposed to an 'input device' - this means there would be no signal.
Are you talking mobile phone apps, custom manufacture eye scanning devices, desktop pc's?
please elaborate.
aaah Patrick Karcher - has the correct answer. plus one for that - i should have been more prepared for coming to stackoverflow on april fool's day.
If you mean getting images from devices without using encoders and drivers, have a look at TWAIN (Technology Without Any Interface). and it's faq.
The most important feature I want to incorporate is that the user need not have a webcam, the app must be able to read the eye from the display device i.e. CRT or LCD screen itself.
are you sure it's possible with the current CRT and LCD technologies? i think you have to have a reading device.
more info from TWAIN.org:
The TWAIN initiative was originally launched in 1992 by leading industry vendors who recognized a need for a standard software protocol and applications programming interface (API) that regulates communication between software applications and imaging devices (the source of the data). TWAIN defines that standard. The three key elements in TWAIN are the application software, the Source Manager software and the Data Source software. The application uses the TWAIN toolkit which is shipped for free.
good lucks.
I know this is an April Fools, but... Actually, if you remove the condition about the fact that it must come from a CRT or LCD screen it might be possible to do it without image capture device attached to their computer.
Possibly using their facebook username and some red-eye photos of them (reflection of the flash off the back of the retina) + a lot of luck and R+D.
Authentication then might simply come from some way of proving that you are the person in the photo.
I am hoping to receive some general guidance on accomplishing a seemingly simple goal. I have a DSLR camera (Canon EOS 50D) and need to write an application that will tell the camera to take a picture. I also need to transfer the picture to the computer and possibly delete it from the camera's storage. A bonus would be to get a live preview from the camera in my application. My environment will be Windows (either XP Pro or Vista Enterprise) and .Net 3.5 (C#).
I have done some research and found a couple of options. One I know will work, but limits me to using only Canon cameras in the future. I have found and downloaded an SDK from Canon that provides a lot of this functionality. I've looked over the SDK and while it's extensive and written in C it does have C# wrappers that will speed up development a bit.
Another option I've found is called Windows Portable Devices. Apparently, it is an API that will talk to devices that implement PTP and MTP standards. It is COM based and as far as I can tell it has no .Net wrappers. This is not however a show stopper. I could P/Invoke the functionality I need or write a Managed C++ DLL to use in my application to talk to the camera.
I am looking for anyone with experience with WPD to give me pointers. I've perused the documentation and seen references to transferring images and deleting images. I have not, however, seen mention of commands to take a picture, get a preview image, or say focus/auto-focus.
The WPD api provides the command WPD_COMMAND_STILL_IMAGE_CAPTURE_INITIATE
I am not sure whether your camera supports it but it should be simple enough to find out. If you can get the "wpdinfo" tool from the driver development kit and start it with your camera connected then send it a WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_COMMANDS command and see if it supports the still image capture command. IF so then you could give that a try.
The comment from TallGanglyGuy is incorrect. ptp does allow you to trigger new images and change exposure, etc. Some cameras have firmware that only exposes some of the ptp commands.
PTP supports common device controls, such as taking a picture, so that
the user could take advantage of the PC/camera combination in new and
different ways again, without requiring additional software.
quoted from http://msdn.microsoft.com/en-us/windows/hardware/gg463507.aspx#EXC
try my Eos Framework: https://github.com/esskar/Canon.Eos.Framework
IMHO it's a better alternative then the .cs file that comes with the SDK.
PTP and MTP are both protocols for transferring files from a digital still camera (DSC). The protocols provide no functionality for triggering new images, or setting exposure control. You will be stuck using the camera specific SDK. If you want multiple vendor support Nikon has an SDK that provides similar support as the Canon SDK for their cameras.
More info on PTP and MTP can be found here:
http://en.wikipedia.org/wiki/Picture_Transfer_Protocol
and
http://en.wikipedia.org/wiki/Media_Transfer_Protocol
EDIT
I forgot to mention that WIA may be interesting to you, assuming your camera's driver provides a WIA interface.
This is really generic, but it may help.
I had to write an application that used two different bar code scanners from two different vendors with different SDK's. I created an interface that defined the methods and events that I wanted to code for, and then wrote adapter classes that implemented my interface.
This worked well in my case, and switching from one to the other was pretty seamless. If you took the same approach, you wouldn't be totally dependent upon one SDK.