Regression in NFIQ2 score ?

[Picard2200]

I have downloaded the last release of NFIQ2, run it and compared the results with a former version (at least 2 years old) that I compiled. First I noticed a change in the interface:

• for the last release version, the calling syntax is "nfiq2.exe -i "
• for my generated version, the calling syntax on a single BMP file is "nfiq2.exe SINGLE BMP false false"

But there is also a change in the NFIQ2 score. And on a specific image, I have a score of 0 with my generated version and an error with released version.

Moreover BMP files saved using OpenCV were accepted with my generated version but rejected with the released version as not at 500 dpi. I had to use Pillow to save the image as being at 500 dpi to BMP (Image.save(bmp_fname, dpi=(500,500))

For me this regression is a big issue and I need to have stable values for NFIQ2 for my project.

[gfiumara]

Hi @Picard2200,

Yes, we vastly improved our the command line executable. Thank you for taking note.

Over the past year or so, we've discovered and fixed many bugs and issues in NFIQ2 that were preventing stable computation of scores. The scores you get now should be stable on all platforms. Stability is 100% our most critical goal on this project. We have been in constant communication with and providing format updates to ISO SC 37 WG3 as we make these changes.

An error many make with NFIQ2 is not using 500 PPI images. This is now enforced with our command line tool. It is not correct for us to assume an unlabeled image is at the appropriate PPI or we risk providing the user erroneous results. We do provide an override flag, -F, that will assume 500 PPI. In the current source (not in the release), we also have this as a yes/no option, as well as an option to resample. However, we encourage you to record the PPI in your image's header. It is unfortunate that OpenCV does not provide this functionality out of the box, but outside our scope.

I encourage you to attend the upcoming NFIQ 2 workshop to learn more about what the community has been up to: https://eab.org/events/program/248

[Picard2200]

Hi Gfiumara, I have noticed the great job that you did and I prefer too resolution to be checked (like BioCTS that did a great job on that). My issue is more regarding an image at 500 dpi (I am sure of this point) that returns an error with the released version and 0 with a former version. The image is degraded voluntarily but resolution is not impacted: we just cropped part of the image and added fake scratches.

[gfiumara]

You mentioned you cropped the image: it's likely the error has to do with the size of the image, and the current source code makes this new error message more clear (we should have a new binary release sometime this or next week). The minutia extractor bundled within NFIQ2 has a minimum dimension requirement that we found was not being met by many images. There was a defect within NFIQ2 in which if the feature extraction failed, NFIQ2 would make a 0 minutia template on its own. This is incorrect, because finding 0 minutia is different than failure to extract. As you may know, a number of features comprising NFIQ2 are based on the location of minutia. It would seem that this error continued to propagate to give you a 0 score in the old version. Failure to extract is now an NFIQ2 error. We feel this is correct behavior.

We have been looking into whether the dimension requirements are actually hard requirements in the feature extractor with the extractor's developers and may be able to lower them in the future.

[Picard2200]

The verb crop that I used may be misleading: the input image has the same size than the reference image (which provides a valid score) but we have removed (blanked) most of the finger surface. But with your explanatioon I may assume that it is leading to a feature extractor error.

BTW, I am already a member of EAB and plan to attend to the NFIQ 2 workshop.