API Change for Reference Database on Disk

59 views
Skip to first unread message

Evaluation of Latent Friction Ridge Technology (ELFT)

unread,
May 18, 2021, 3:32:57 PM5/18/21
to Evaluation of Latent Friction Ridge Technology (ELFT)

Hello ELFT participants, 

After our request for template sizes, we heard from several organizations that would require more storage for their reference database than NIST could reasonably facilitate in RAM. We have changed our API to allow for larger storage capabilities using local disks.

  1. Reference templates will be provided to createReferenceDatabase in a TemplateArchive instead of a std::vector in RAM. A TemplateArchive is a two-file structure: a concatenation of templates and an ASCII manifest with identifiers and file offsets. If your organization has participated in NIST’s FRVT 1:N evaluation, TemplateArchive is identical to FRVT’s "Enrollment Database (EDB)."
  2. SearchInterface introduces a new method, load. Use this method to load any information you'd like from disk into RAM for faster access during search. This means you should not load significant quantities of data from disk into RAM during construction of SearchInterface implementations.

As a note, the paths provided in SearchInterface::getImplementation will now not be guaranteed to be on a RAM disk, and will more likely be on a local SSD for your exclusive use. The speed of the disk at the path provided will be the same for all participants.


Database Modification

We heard from a few organizations that modifying the database and persisting those changes created significant hassle and would not be efficient. To that end, we have removed all database modification methods. The database created during createReferenceDatabase will never be modified.

 

Other Changes

Since we were otherwise breaking the existing API, we also made some smaller changes that we hope improve your experience:

  • createTemplate and search allow you to return information that would have been returned from extractFeatures and extractCorrespondence respectively.  This remains optional, but highly appreciated for future NIST forensic science research projects.
  • Correspondence has new and changed members:
    • referenceIdentifier: such that the sort order of Correspondence and Candidate do not have to remain the same.
    • probeIdentifier: such that Correspondence can stand alone.
    • type: a new enumeration indicating the type of correspondence.
  • Return Correspondence in a CorrespondenceResult (previously a verbose optional tuple).
  • CreateTemplateResult and EFS have an additional optional bool complex, that can be populated if the algorithm interprets the analysis or comparison was complex.

The API and validation package have been updated on our GitHub. Please review and let us know if these changes work for you or if you believe we made any errors during our changes.

Thanks for your patience. We continue to look forward to your submissions!

-Greg (@nist.gov)

Reply all
Reply to author
Forward
0 new messages