I am looking for SDKs which can do finger print matching. Rest of my code is mostly in C so I prefer if the SDK has C API's. Also it would be great if the SDK is free. Does anybody has experience with these SDKs and recommend any particular SDK? Also, while looking in these SDK what are the important features I should concentrate?
I've used two SDKs in the past, but only as a C# developer. Both the SDKs below say that they support C:
Griaule Fingerprint SDK (requires paid-for license)
Digital Persona OneTouch (free sdk)
A quick summary of features to consider:
Are you verifying that a fingerprint matches that of a known user, or identifying a user from a single fingerprint?
The Griaule SDK implements both Verify and Identify patterns.
DigitalPersona's free SDK only supports Verify - to Identify, you have to loop through all the fingerprints in your database and see which one matches best. They state that this is 'inefficient', but if you have very few users (< 200), it seems quick enough.
Adjustment of discrimination sensitivity (false positives/false negatives)
Balance up how closely a print must be identified. A high sensitity may cause a legitimate user's prints to be rejected, but a low sensitivity may match one users' prints to the wrong user. Assess the impact of each case and code accordingly.
The deployment overheads differed - the DP components came with a merge module, but I only recall seeing standalone installs for Griaule.
What fingerprint capture devices are you intending to support? Check very carefully that the SDK will support yours!
Check the licensing terms very carefully the Griaule costs can be substantial based on the number of clients you expect to roll out to.
The Griaule SDK required a license file be deployed, both on client and server.
DP (free edition) did not.
The .NET DP SDK came with a visually pretty, and easy to use, fingerprint registration dialog, but the version I downloaded (v1.4.0) had a bug with the fingerprint capture component taking up to 10 seconds to initialise. I don't know if this has been resolved yet. However, it was straightforward to code a bespoke UI.
Overall, I favoured the DP SDK, but it was a close-run thing. Basically, being license-free and better documented suited me more.
You can use Innovatrics IDKit PC SDK. You can get a free version for 6 months. This provides a C API as well as a C# API. I have been extremely impressed with this package.
If your platform is not a PC, there are packages for other platforms as well.
This is very useful with detail information about fingerprint integration with windows based software: http://www.codeproject.com/Articles/38881/Fingerprint-Reader-Integration-using-the-M-SYS-SDK This integration was using this fingerprint sdk. It solves problems with low level free sdks and also supports other biometric modality.
This is a really simple question, but the answer is really complicated. Most of the Free or at least royalty free matching SDKs are tied to a vendors fingerprint scanner. If you are wanting to use one of those SDKs you will have to commit to their scanners.
The next question is how is the software going to be used. Fingerprint matcher tend to fall into one of two categories, 1 to 1 or 1 to N. 1 to 1 is assuming you know who the user is and you want to just VERIFY their identity with a fingerprint. 1 to N searches through a database of users and finds them by their fingerprint. Depending on the size of your user population, if you are doing 1 to N you may need to confirm the performance of the algorithm first to ensure it will meet your needs.
The other option that you have is there are fingerprint scanners that do what is known as match on device. These scanners have embedded matching algorithms and databases that do all the work for you. You get all the licenses you need when you buy the fingerprint sensor. These are really useful in embedded applications.
Related
I am trying to develop a library of shared code for my company.
We are developing on a technology by SICK called AppSpace, which is designed for machine vision. AppSpace is a stand alone eco-system, beneath which there comes a variety of SICK programmable devices (e.g. programmable cameras, LiDAR sensors), and an IDE with which these can be programmed. Programs are written in Lua, using HTML/CSS for the front end.
AppSpace provides a Lua API for these devices.
In my company, a few of us write applications and it is therefore important that we create a library of shared code to avoid redundancy / rewritten code.
However, each firmware version of each device has a corresponding API version. That is to say, that on a given device the API can change between firmware versions, and also that API versions differ across devices. Two devices will have two different sets of API functions available to them. Functions they share in common may also have slightly different implementations.
I am at a loss as to how such a situation can be properly managed.
I suppose the most "manual" route would be for each device to have its own partial copy of the library, and to manually update each device's library to have the same behavior each time a change is made, ensuring that each device conforms to its API. This seems like bad practice as it is very error prone - the libraries would inevitably become out of sync.
Another option might be to have a master library, and to scrape the API documentation for each device. Then build a library manager which parses the Lua code from the library and identifies missing functions for each device. This seems completely impractical and also error prone, probably.
What would be the best way to develop and maintain a library of shared code which can be run on multiple devices, if it is even possible?
I would like to answer this and review some of the topics discussed.
First and foremost; functions that are shared in common between devices will be implemented differently by means of the compiled code on the respective device (i.e. PC, 2d camera, 3d camera, LIDAR, etc) while the functionality maintains the same between them all. This way the code can be readily ported from one device to another. That is the principle of the SICK AppEngine that is running on all SICK AppSpace devices as well as 3rd party hardware with AppEngine installed.
The APIs embedded into the devices are called a CROWN (Common Reusable Objects Wired by Name) component and can be tested against nil to determine if they are exposed APIs. Here's an example of an CROWN called 'IMAGE'. If it exists than you could run this code when it does.
if IMAGE then
--do code
end
SICK also has a AppPool that you can upload your source code to and it will test all the required CROWNs and return a list of all SICK devices that can run properly.
How do you handle a bug in a specific SDK version in a released application? Say for example I've reported and received notification that a bug is known in a specific version of an SDK. Say the SDK engineers fix the problem in the next release. Do I then need to check if the user is running the buggy release and display an error message that they can't use a specific feature with a bug in it because it will crash their hardware? Is there a more graceful way? Do you display an alert and tell them to upgrade to the latest SDK? Do you completely remove the feature? Advice would be appreciated.
This is phrased to be agnostic as possible, but I am asking for the purposes of iPhone application development at this time. General answers for other platforms would be nice as well.
It depends on the nature of the bug and on the nature of the platform. With the iPhone, for example, you cannot just tell the user to upgrade his or her phone. If your goal is to support iPhone version X.Y, then you will need to support the corresponding SDK; whereas, targeting browser X version Y.Z or Java version X.Y, it may sometimes be acceptable to tell users to upgrade.* Giving the impression that your application can do something only to give an error message saying that it cannot support it for that version of the platform does not make for a good user experience. If possible, try to work around the deficiency in the platform (by possibly reimplementing code that supposedly works in the SDK) and provide the feature to the user. If that isn't possible, then disable it when running on the deficient version of the platform, but be sure to remove all traces of that feature from the application (so that users don't click on a button only for it to tell them that the button is completely useless). I should add that conditionally enabling/disabling features is only sensible in the case where the feature is not essential to application; if a feature is a core aspect of the application, then you'd better find a workaround or raise the minimum requirements as it would not be appropriate to ship a deficient application to your users.
*An example where telling users to upgrade is not reasonable would be business applications, since business sys admins tend to be unusually lazy and users have no power to upgrade by themselves.
I just downloaded Embarcadero Delphi 2010 (the trial version).
tasm32 and the related stuffs (ilink32, implib, impdef, etc) are still available in it.
Still they lack header files and import libs, but fortunately that can be solved by win2inc, implib, etc.
The final result can be called TASM32 SDK (in a similar way like MASM32 SDK do).
Considering Delphi is a commercial product, I plan to use this SDK for personal usage only (and of course non commercially).
Is this legal or not?
"Is this legal or not?"
That depends on the country.
Also, "legality" doesn't have a binary yes/no value (instead the result may depend on arguments made in a court of law, if the question ever even goes to court).
I am developing a Netflix application for BlackBerry mobile devices. I need to make a decision as to the minimum OS version that I should develop for - depending on which I choose will have some design impacts (such as what browser field classes I can use, etc.)
What it comes down to is..should I support anything lower than OS 5.0?
I would say 4.5 and newer. see also:
OS - What market share do each of the BlackBerry models have?
OS - Which BlackBerry OS version to target for?
OS - What is the best practise in blackberry for reaching the widest range of smart phones?
I think there a few things to consider. First off, you need to have a clear vision of what you are hoping to achieve - features/functionality. Then evaluate the various API revisions, and determine which API level will provide the facilities needed to achieve your goals. Depending on the outcome of this, you may have to revise your goals. Maybe even consider using a lower API version, rolling out with a reduced feature set to help get your foot into the market, then in parallel be working on the full bells and whistles release utilizing a higher API version. But most importantly, you need to evaluate your market. The question becomes: "Does your target API provide you will enough of a potential market for your app?" But sometimes it becomes a difficult juggle, especially if you embrace the concept of "Build it and they will come" and you develop your app for the bleeding edge - waiting for the masses to arrive. You need to be sure to have the coverage in place (ie. financial, and political if you are in a large corporate environment) to survive until the day arrives. If you haven't already, you may want to look into becoming a Blackberry Alliance member. Also, don't be afraid to engage the major carriers in your market and push them a bit. They should be able to give you a bit of visibility into handset/platform penetration. Evaluate all of the variables both technical and business plan, and document it - the answer will come to you. Hope this helps.
RIM have created an official page with statistics that help you figure out the answer to this question: http://us.blackberry.com/developers/choosingtargetos.jsp
For example, as of November 2010, OS 5.0+ made up less than 50% of the market share of all active Blackberry devices, but OS 5.0+ accounts for 75% of free app downloads and 86% of paid app downloads from App World.
ON the basis of API similarities and supports i can divide os range like this
(A).<4.2
(B). 4.2< and <5.0
(c). 5.0
We deploy to 4.3, 4.7, and 5.0 with our app and that covers almost every in-market device being used today. There may be a few people still running 4.2 but not many.
Every indication I have, based on my experience in embedded computing is that doing something like this would require expensive equipment to get access to the platform (ICE debuggers, JTAG probes, I2C programmers, etc, etc), but I've always wondered if some ambitious hacker out there has found a way to load native code on a Blackberry device. Anyone?
Edit: I'm aware of the published SDK and it's attendant restrictions. I'm curious if anyone has attempted to get around them, and if so, how far they got.
I've seen this question pop up in a number of different forums over time. The original Blackberries were programmable in C++ but I think that RIM ran up against the problems of trying to implement a secure platform in the C/C++ compile to native paradigm.
The devices do have JTAG ports, but unless one could get hands on the RIM code as a place to start the problem is enormous.
I also have to wonder how useful a Blackberry with a replacement FOSS operating system would be, since it would not likely have the protocols to connect to BES or BIS, send PIN's etc. If one was simply looking for a the power of the hand held computing platform I suspect there are many more likely candidates available.
No, C++ is no longer a supported RIM development tool, as they phased it out a number of years ago. Client applications can be developed in Java (or one of a few 5GL frameworks), and web + sever-side apps can be developed using standard tools.
For those looking for updated information, the new Playbook os, also known as QNX, also known as Blackberry 10 (or it will be when the phones running it come out) is in fact c/c++ based, also using QML and a C++ add on called Cascades.
Unfortunately the official SDK website only seems to mention Java. According to wikipedia, different versions of the BlackBerry use different processors. Combined with the fact that RIM uses a proprietary operating system for the devices, it becomes pretty difficult to develop native code without official tools. There is also a partial API-level security restriction which would further prohibit advanced tinkering.
Just randomly searching for an answer to this and came across http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Native-C-C-SDK/td-p/778009 which mentions that BB intend to release a C/C++ SDK soon, more details will be provided at the 2011 Game Developer Conference.