I have to develop an sdk for biometric applications, but don't know how to start development. Either I need to write my own algorithm or use written by other and are free. If I use others algorithm then it is difficult to say about the quality and results.
Is there any standard source available that can help me in term of quality.
I don't wanna use any available sdk
Anybody who can help me in this regard will be a plus for me.
Thanks
Khizar
Programming for biometric devices depends largely on the device you use. Chances are you've received software with your device that has its own evaluation algorithim which then outputs a value, usually a hash, that your program can then handle.
If you're looking for a generic option, Google has several. One option being m2sys.
Related
I want to write a app (initially Windows) that include handwriting to text recognition. I want to use the Windows built-in Tablet PC INput. My question is is there a way to capture the strokes as an image, "send these to the OCR engine used by the Tablet Input, and return the recognised text?
Or, are there any good open source handwriting libraries that could be used directly?
The primary development language is Qt.
I am not aware of any open source or free software libraries for handwriting recognition, so I wrote an adapter. My target was my tablet PC running Linux, but part of my solution can also be used directly on Windows, although you will need to adapt it to your needs.
You will need to read through the licenses for the components I used and validate your own use of them.
The source is available here: Ink2Text project
Part of this solution is a server which uses the XP Handwriting Recognition libraries to interpret the strokes which make up handwriting. As an aside, this does not use OCR - it uses connected graphs of the flow of the strokes.
Another complementary project provides a client handwriting widget: Stylus/Handwriting Input Panel. This is written in Java, and it's GPL3. It accepts the handwriting and sends it off to the server. Unless you wish to use it as is, it's of value solely to see the data format for the ink, although that's simple enough and you can probably deduce that with just the Ink2Text source code.
An earlier solution used the S/HIP with my MS Ink Server, which accepted input over regular network connections. That may also be useful depending on your architecture, but requires a running copy of Windows.
This system provides very good recognition of printed and cursive handwriting.
I will answer questions about it only in it's associated SourceForge forums, so that others may benefit from the answers as well - please don't ask here.
Cheers,
Bret
I want to be wrong, but unfortunately, there is no available open-source offline handwriting recognition system even close to MS' or Apple's Ink.
On Windows you can play with Ink Recognition (About Handwriting Recognition, Advanced Recognition Sample). C++ interface is available, but not as well documented, as .net implementation is. So, you need to apply more efforts and do a lot of research to achieve what you want.
For another systems (including Windows too) there is way to use Tesseract-OCR with your application. See Tesseract's base api. For better recognition quality, you may train tesseract and use your own trained data.
If you do not want to spend your time doing R&D tasks above, you can use paid solutions like: MyScript SDK, WritePad SDK and so on...
I am a beginner and I need a graphical simulator to write assembly programs based on 68000 microprocessor. I have found Easy68K simulator. It works and the features are good, but is there any newer/better graphical simulator than Easy68K? I need the most uptodate one.
Latest version of EASy68K emulator is v5.12.29 at the moment. You can find this information (and follow the updates) at EASy68K forums. You can download latest version from the URL below;
http://www.easy68k.com/
If you want some graphical simulation, you may like to use an emulator of a computer using 68K CPU like Commodore Amiga or Atari ST. I prefer UAE Amiga emulator. Of course you need to learn about Amiga hardware and stuff but you may also like the experience, test your 68k routines, see or hear the output.
My advice may not be suitable for your needs. But you already know about EASy68K and i know no better way than Amiga/Atari ST emulators myself.
You may want to check out BSVC.
But this depends on what you mean by "graphical" simulator...BSVC has a graphical user interface, but doesn't simulate graphics. Hope that helps!
Voxeo provide a free IVR for development purposes, but I was wondering if there is a much simpler form of test IVR, perhaps which runs on the local machine and uses your microphone and speakers instead of the telephony network?
You should be able to do this with any VoiceXML IVR that supports SIP in combination with a softphone. There are a variety that do, including Voxeo. For a lower cost solution, you might be able to do something with Asterisk and the VXI* based browser that runs on the platform.
Note, be aware that VoiceXML browsers vary from platform to platform. This may or may not be an issue for you when developing and testing your application. You can write fairly portable applications with just a bit of experience across platforms, but if you are new to VoiceXML, knowing how just one platform has implemented the specification can get you into trouble.
As a different approach, you could look at Voiyager that also allows you to drive the call flow with text input or via a programming interface. Disclaimer: I am part of the development team and company that produces Voiyager.
We need a paid for supported Encryption / Decryption API for a project - AES >256?
I dont want the developers coding their own encryption / decryption even using the built in stuff. To many chances to go wrong.
Links to sites much valued.
UPDATE
Due to the fact as many have said - Its hard to understand if you are not familar with encryption, and get a small thing wrong and its busted...
I have seen answers and will be getting our own encryption/decryption from the builtin - but all the team will need to peer review.
For information BlowFish.Net is good, and performs faster than the builtin crypto routines, which when you start to look at encrypting/decrpyting data into a database can have some massive perf issues ...
http://www.codinghorror.com/blog/archives/001268.html
"even using the built in stuff"
The reason that it's built in is so that people have tested, reliable algorithms available to use that implement standards, not black box third party APIs that might not. What are the "chances to go wrong"?
Maybe you need to switch to Java, you can always opt to use third party JSSE providers there if you're paranoid about the built-in provider.
Bouncy Castle is a well respected and well developed .NET encryption library that is usually recommend for these sorts of questions. But what's wrong with using the System.Security.Cryptography Namespace? - it is extremely secure, very fast and doesn't require any external libraries. Here's an example of how to implement it.
Oh, and "using the built in stuff" will mean it is less likely to go wrong. Your developers won't be coding their own classes, just using the interfaces available which are easy to use and have been very rigorously tested.. Also, the "built in stuff" will be well supported by Microsoft, so if you want to upgrade to C# 4.0 (or C# 5.0 in the future?) you probably won't need to change your code at all.
If you were to use a 3rd party library you would most likely still run into the same issues, which basically boil down to not understanding the pitfalls of encryption.
Without a decent understanding you'll most probably make mistakes with key management, or using bad initialisation vectors or keys. These are issues you'll need to understand to tackle regardless of whether you use the inbuilt libraries (which are fine), or a 3rd party library.
If its something you feel worried about enough, the best recommendation is probably to bring in someone, or better yet - train up people to understand encryption.
Use the builtin 'stuff'. But make sure you use it in the correct mode.
Our company is using some software that ONLY accepts input from an "Imaging Device" i.e. a TWAIN device (e.g. scanner).
The problem is that we are receiving our files digitally, so using an actual scanner would require us to print, scan, and shred documents that we already have on the computer, but not in the software.
I was curious if anybody has any idea of how we might be able to work around this problem in the meantime. My first thought was to find some way to trick the program into thinking we're using a scanner, via some new 'imaging device' that would just read in the file, and spit it out to the software, but I don't even know where to begin with that.
We put in a feature request, seeing as how this problem should obviously be addressed in the software itself, but the company is notorious for lagging pretty hard when it comes to updates.
The system used by scanners is called TWAIN, so you'd be looking for some sort of virtual twain driver.
A quick google search will produce several hits, I don't have any experience with the software myself so can't advise any further.
Two such providers I found via experts exchange:
http://www.twaintools.de
http://www.scanpoint-usa.com
OK, months late... but in case you are interested, I have a TWAIN driver framework/toolkit that might let you build this fairly easily, depending on just what your scanning app expects, and how hard it is to read images from your digital documents. It's a Microsoft Visual C++ project. No charge but you'd need our permission to redistribute a driver based on it: GenDS
The TWAIN Working Group also has a sample/skeleton driver, I think it's straight C - and used to have some rather bad bugs (Why I wrote mine ;-) but, it might have got better.
Look for the "sample data source and application" on their download page.
And of course I have a 'commercial' version of GenDS that I use to write TWAIN drivers on contract.