Personal tools
You are here: Home Dataset vera-fingervein

The Idiap Research Institute VERA Fingervein Database

The VERA Fingervein Database for fingervein recognition consists of 440 images from 110 clients.

This Database was produced at the Idiap Research Institute in Martigny and at Haute Ecole Spécialisée de Suisse Occidentale in Sion, in Switzerland.

Acknowledgement

If you use this database, please cite the following publication::

  @inproceedings{Tome_IEEEBIOSIG2014,
         author = {Tome, Pedro and Vanoni, Matthias and Marcel, S{\'{e}}bastien},
       keywords = {Biometrics, Finger vein, Spoofing Attacks},
          month = sep,
          title = {On the Vulnerability of Finger Vein Recognition to Spoofing},
      booktitle = {IEEE International Conference of the Biometrics Special Interest Group (BIOSIG)},
           year = {2014},
       location = {Darmstadt, Germay},
            url = {http://publications.idiap.ch/index.php/publications/show/2910}
  }

Database Description

All fingervein images have been recorded using the open finger vein sensor described in [Ton+12].

110 clients presented their 2 indexes to the sensor in a single session and recorded 2 images per finger with 5 minutes separation between the 2 shots.
Results is a Database of 440 images of fingervein images.

The recordings have been performed at 2 different locations, always inside buildings with normal lightening conditions.
The first 78 clients in the Database are from one location and the remaining 32 are from another.

The Database is composed of 40 women and 70 men whose ages are between 18 and 60 with an average at 33.
Information about gender and age of clients are given as metadata for each client ID in the text file METADATA.txt.

Images are labeled as follow: ID_index_shot.png where "ID" is a 3 digits number that stands for client's ID, "index" stands for the considered index which can be "R" or "L" ("Right" or "Left"), and "shot" stands for the considered shot number which can be "1" or "2" (2 shots per finger).

Images from the same client are regrouped into a single folder labeled as follow: ID-Gender, where "ID" is a 3 digits number that stands for client's ID and "Gender" stands for client's gender which can be "M" or "F" ("Male" or "Female").

The format of the images is PNG.
Size of the images is 665 x 250 pixels.
Size of the files is around 80 kbytes per images.

* Example of the nomenclature fot the client #29:
* 029-M/029_L_1.png
* 029-M/029_L_2.png
* 029-M/029_R_1.png
* 029-M/029_R_2.png

Here is an example of images from the database:

.. image:: images/029_L_2.png
.. image:: images/029_L_1.png
.. image:: images/029_R_2.png
.. image:: images/029_R_1.png

Database Protocol

Clients were asked to put their index in the sensor and then adjust the position such that the finger is on the center of the image.
Bram Ton's Graphical User Interface (GUI) was used for visual feedback, Near Infra Red light control and acquisition.
When the automated light control was performing unproperly the operator adjusted manually the intensities of the leds to achieve a better contrast of the vein pattern.

Clients first presented an index, then the other, a second time the first index and a second time the second index.
The whole process took 5 minutes per clients in average.

.. [Ton+12] *B. Ton*. **Vascular pattern of the finger: biometric of the future? Sensor design, data collection and performance verification**. Master's thesis, University of Twente, July 2012.

 

Protocols for the VERA Fingervein Database

This file contains a description of the protocols for the VERA Fingervein Database. As of today, the protocols only describe a posteriori evaluation scenarios. Some of the protocols reserve data on the database for the training of your algorithms, others don't. In such cases, you must pre-train your matcher using a different dataset and only apply it here for retrieving the results on this database.

Because each person's finger is different, each finger is considered one separate identity. Since the database contains data of both index fingers from 110 different people, there are 220 different "identities".

Protocol File Structure

There are 4 protocols defined by the database. Each protocol is organised as a set of 3 files comprising:

  • The training data
  • Evaluation data:
    • Data to be used for enrolling models of a client
    • Data to be used for probing enrolled models of clients against the same or different clients (impostors)

Each file in a protocol is organised in this way:

  • Training data (filename train.txt): A single text file, with one entry per line containing:
    • filename: The name of the data file, relative to the common root of all data files, and without file name extension. The filenames are defined as <client>-<gender>/<client>_<finger>_<session>. With:
      • <client> being the client number formatted such as %03d. Example: 034.
      • <gender> being the client gender, formatted as M (male) or F (female)
      • <finger> being the client index finger side, formatted as L (left) or R (right)
      • <session> being the session, formatted as 1 or 2. There were only two acquisition sessions on this database.
      • Here is a full example: 034-M/034_L_1
    • client_id: A unique (string) identity for the client. The client identity assumes the format <client>_<finger>.
  • Enrollment data (filename models.txt): A single text file, with one entry per line containing:
    • filename: Same as before, with different files
    • model_id: A unique (string) identity for the client. The client identity assumes the format <client>_<finger>_<session>, with each field described as before.
    • client_id: Same as before, with possibly different clients
  • Probing data (filename: probes.txt): A single text file, with one entry per line containing:
    • filename: Same as before, with different files that may or not exist in the enrollment or the training sets.
    • client_id: Same as before, with possibly different clients

In order to implement the evaluation protocol and compare to our published results, you must ensure a model is enrolled for each row in the enrollment data file and then it is probed against all probes (lines) in the probing data file. Scores for genuines are those matching models for a given <client>_<finger> with probes for the same client. All others are to be considered impostors.

Protocols

We have setup 4 evaluation protocols on the VERA Fingervein database. They are:

  • Nom: The Nom protocol corresponds to the standard verification scenario. For the VERA database, each finger for each subject will be used for enrolling and probing. So:

    • 110 clients x 2 fingers = 220 unique fingers
    • 2 sessions per finger, so 440 unique images
    • Use Session 1 for enrollment and Session 2 for probing
    • Total of 220 genuine scores and 220x219 = 48180 impostor scores
    • No images for training
  • Fifty: Similar to the Nom protocol, but only using the first fifty subjects of the database (numbered from 001 till 059). It was done to run quick tests. So:

    • 50 clients x 2 fingers = 100 unique fingers
    • 2 sessions per finger, so 200 unique images
    • Use Session 1 for enrollment and Session 2 for probing
    • Total of 100 genuine scores and 100x99 = 9900 impostor scores
    • Use all remaining images for training (440-200 = 240 images). In this case, the remaining images all belong to different clients that those on the development set.
  • B: This protocol was created to simulate an evaluation scenario similar to that from the UTFVP database. 108 unique fingers were picked:

    • Each of the 2 fingers from the first 48 clients (96 unique fingers), clients numbered from 001 till 057
    • The left fingers from the next 6 clients (6 unique fingers), clients numbered from 058 till 065
    • The right fingers from the next 6 clients (6 unique fingers), clients numbered from 066 till 072

    Then, protocol B was setup in this way:

    • 108 unique fingers
    • 2 sessions per finger, so 216 unique images
    • Match all fingers against all images (even against itself)
    • Total of 216*2 = 532 genuine scores and 216*214 = 46244 impostor scores
    • Use all remaining images for training (440-216 = 224 images). In this case, the remaining images not all belong to different clients that those on the development set.
  • Full: This is similar to the protocol B in the sense it tries to match all existing images against all others (including itself), but uses all clients and images instead of a limited set. It was conceived to facilitate cross-folding tests on the database. So:

    • 220 unique fingers
    • 2 sessions per finger, so 440 unique images
    • Match all fingers against all images (even against itself)
    • Total of 220*2 = 440 genuine scores and 440*438 = 192720 impostor scores
    • No images for training

 

 

 

 

Contact

Mr. Matthias Vanoni
Dr. Pedro Tome
Dr. Sébastien Marcel


Idiap Research Institute
Centre du Parc - rue Marconi 19
CH-1920 Martigny, Suisse
Phone: +41 27 721 7727
Fax: +41 27 721 7712

Document Actions