Challenge 1: Liveness Detection in Action

This Challenge is available for either contact and contactless fingerprint or both.  

Please indicate during registration.

In real applications, the Fingerprint Liveness Detection system works together with a recognition system in order to protect it from spoofing attacks. Competitors are invited to submit a complete algorithm able not only to output the liveness probability (liveness output)  but also an integrated match score (IMS output) which includes the probability above with the probability of belonging to the declared user.

In last years it was noticed that the existence of artifacts due to the human skin (person-specific) and to the particular curvature of ridges and valleys (finger-specific) can impact in liveness detection systems’ performance and can be exploit to improve the integrated system. In particular, the data acquired during the recognition system’s initial enrollment phase can be used to lower the liveness error rate and consequently, to improve the integrated system performance. For this challenge, participants can decide whether to exploit the additional information coming from the enrolled user (“user-specific effect”).

Each submitted algorithm must be a Windows or Linux console application with the following list of parameters:

Synopsis:  [nameOfAlgorithm].exe [ndataset] [templateimagesfile] [probeimagesfile] [livenessoutputfile] [IMSoutputfile]
[nameOfAlgorithm].exe – It is the executable name. Format: Windows or Linux console application (es. .exe) [ndataset] – It is the identification number of the dataset to analyse. Legend:
  1. GreenBit
  2. Dermalog
  3. Unkown1
  4. Unknown2
[templateimagesfile] – A text file with the list of absolute paths of each template image registered in the system. Each image is in the same format of own train set. Example of a [templateimagesfile] called GreenBit_template.txt: G:\Works\LivDet2025\TemplateImages\GreenBit\0123.png G:\Works\LivDet2025\TemplateImages\GreenBit\1323.png G:\Works\LivDet2025\TemplateImages\GreenBit\0033.png G:\Works\LivDet2025\TemplateImages\GreenBit\0954.png G:\Works\LivDet2025\TemplateImages\GreenBit\2154.png [probeimagesfile] – A text file with the list of absolute paths of each image to analyse. Each image is in the same format of own train set. Example of a [probeimagesfile] called GreenBit_probe.txt: G:\Works\LivDet2025\ProbeImages\GreenBit\0123.png G:\Works\LivDet2025\ProbeImages\GreenBit\1323.png G:\Works\LivDet2025\ProbeImages\GreenBit\0033.png G:\Works\LivDet2025\ProbeImages\GreenBit\0954.png G:\Works\LivDet2025\ProbeImages\GreenBit\2154.png [livenessoutputfile] – The text file with the liveness output of each processed image, in the same order of “probeimagesfile”. The output is a posterior probability of the live class given the image, or a degree of “liveness” normalized in the range 0 and 100 (100 is the maximum degree of liveness, 0 means that the image is fake). Scores [0, 50) classify fingerprint image as “fake” while scores [50,100] classify fingerprint image as “live”(in Fig.1 in blue “livenessoutput”). In the case that the algorithm has not been able to process the image, the correspondent output must be -1000 (failure to enroll). Example of a [livenessoutputfile] called GreenBit_liveness_results.txt: 100 54 -1000 32 78 [IMSoutputfile] – The text file with the integrated match score output between the processed image (probe) and the corresponding template. The output is a combined posterior probability of the live class and the belonging of the claimed identity given the image, normalized in the range 0 and 100 (100 means that the image is live and belonging to the declared user, 0 means that the image is fake or belonging to an attacker). Scores [0, 50) classify fingerprint image as “fake or attacker” while scores [50,100] classify fingerprint image as “live and genuine” (in Fig.1 in red “IMSoutput”). In the case that the algorithm has not been able to process the image, the correspondent output must be -1000 (failure to enroll). Example of a [imsoutputfile] called GreenBit_ims_results.txt: 100 54 -1000 32 78

Fig.1 Block diagram of a possible Integrated Match System comparison

Each parameter related to the dataset configuration must be set before submission. Each competitor can configure his algorithm by the training-set available after the registration. Only Windows  or Linux console applications with the above characteristics will be accepted for the competition.

Participants are recommended to send a description of their algorithm.

They may publish also the source code of their algorithm, but this is not mandatory.