Document Title Here
AET65 API
Version 1.0
idvation GmbH
Otto-Hesse-Straße 19 / T5
Phone +49 6151 9926567
D-64293 Darmstadt
Fax +49 6151 3689296
www.idvation.com
Title Here
Page 10 of 84
including multiple biometric operations on one FM. If multiple threads call BSAPI.DLL function which
communicates with FM, one of the calls is blocked (for caller it seems that the operation is still processing)
and it is resumed after the thread communicating with the device is finished.
If the function being suspended is an interactive operation, the application is informed about the situation via
the ABS_CALLBACK. See documentation of messages ABS_MSG_PROCESS_SUSPEND and
ABS_MSG_PROCESS_RESUME for more information.
The only exceptions are functions ABSInitialize and ABSTerminate. These two functions are not thread-
safe. This is usually not a problem, because they are called as part of application initialization and termination
respectively.
3.1.5.
Anti-latent Checking
In general the goal of the anti-latent check is to minimize the negative impact of residual fingerprint left on the
surface of area sensor. This negative impact has two forms – security (risk of a false accept) and convenience
(risk of false reject due to the lowered image quality).
Note that for strip sensors, such checking is never performed because there is no danger, so for these
sensors the API automatically reports the last scan as not being latent.
There are two ways how to perform the anti-latent checking. The first one is built-in high level biometric
operations: enrollment and verification. I.e. calling ABSEnroll() or ABSVerify() automatically involves the anti-
latent checking and the function does not return with templates evaluated as latent ones. Instead it asks user
to clean sensor and scan finger again with appropriate callback messages. This implicit anti-latent checking
can be turned off and on by setting global parameter ABS_PARAM_LATENT_CHECK. By default the
checking is enabled.
The second way is to call ABSCheckLatent manually. BSAPI remembers automatically in a context of session
last scanned image, and when this function is called it checks whether that scan is or is not latent.
Note that the logic of each check (implicit or explicit with ABSCheckLatent) is as follows. The last scanned
image is compared with the last swipe which was considered as a valid one. If the two are same (according to
the latent check algorithm), the result of the check is positive. If the two scans differ, the last scan is
automatically stored as the last valid scan, so any subsequent checks mean that the last swipe is compared to
this last scan.
This has one side effect: you should not make multiple latent checks after single scan because only the first
anti-latent check will return any meaningful data. This includes implicit checking, so you should not call
manually ABSCheckLatent after ABSEnroll or ABSVerify unless you disable the implicit checking by the global
parameter ABS_PARAM_LATENT_CHECK.
