NIST logo
 

SlapsegII Frequently Asked Questions - FAQ

 

August 4, 2008:

 
  1. What hardware and OS is being used for the test? Hardware:Dell 1855 Blades with Dual 2.8GHz Xeon Processors and 4GB of memory. OS: Windows 2003 server with service pack SR2, Debian Linux, Redhat Linux 4.0, or Redhat Linux 5.0 (64bit).

July 22, 2008:

 
  1. Do the output coordinates we provide for two inch slaps have to form a rectangle, or can the bounding shape around each fingerprint be a quadrilateral that is not rectangular?The ground truth for 2 inch data uses rotated rectangles and the error measure for these slaps will use tolerances based on the ground truth. It would probably work best if the segmentation did return a rotated rectangle. In fact, the original intent was for segmentation to return a rotated rectangle but by using the type-14 record definition from the ANSI/NIST ITL 1-2007 standard the coordinates returned are not forced to form a rectangle and that will not be checked during scoring.

July 18, 2008:

 
  1. Is the submission of validation results the official start of participation? No, participants can withdraw anonymously until software is submitted for testing.

  2. Will any of the test slap images have inversed dynamics (ie. white ridges on a black background)? No

July 14, 2008:

 

  1. Regarding "half amputated" fingers, at which point shall we respond it as "missing finger or -1"? Is there any guideline? The ground truth segmentation boxes for this evaluation were marked to preserve any fingerprint ridge information above the crease. BUT, there do not appear to be any segmentation boxes less than about 50 pixels in height (final error checking of ground truth is still be completed).

June 23, 2008:

 
  1. Does the "ground truth" segmentation box include the "frame line" for inked images? NOTE: This only applies to 2 inch inked data as 3 inch slaps are all live-scan. Generally, the four finger slap image is cropped at the "frame line" of the finger card. If there are any frame lines inside the four finger slap image that crosses through a fingerprint, the ground truth box will still included the entire fingerprint image and not stop at the "frame line". No image processing will be done to remove the frame lines from the fingerprint image.

  2. Live-scan images are sometimes printed on paper and then scanned by a card scanner. Are these images included in SlapSegII data and are they considered live-scan or paper? NOTE: This only applies to 2 inch data as no 3 inch slaps have been "rescanned." This "rescanned" data could occur in the 2 inch data and the source input to the segmentation algorithm would be paper (P).

June 20, 2008:

 

  1. Will testing include "film" between the platen and the fingerprints in place of the friction ridges? No, this is only being done with validation data because NIST can't give out any SBU data.

June 17, 2008:

 

  1. Will testing include inverted hands (ie. input a left hand image and say it is a right hand)? We are not planning to switch the left and right hands.

June 13, 2008:

 

  1. What maximum angle of image rotation could be in 2 inch data? The angle of rotation in 2 inch data varies. The majority of the data is between 0 - 45 degrees rotation. The current maximum value in the ground truth (which is still being done) is 54 degrees.

June 2, 2008:

 
  1. Can a vendor have multiple submissions? Yes a vendor can have two submissions in the first phase AND NIST is likely to continue the SlapSegII evaluation testing at some point after releasing the first phase results.

  2. I would like to request NIST to extend the Software Submission deadline so that some participants will have time to access "3-inch slap image" and to improve slap segmentation for those data. There are no plans to extend the dealine at this time.

  3. It is stated that "On average, segmentation software should take much less than five (5) seconds to segment a slap image "(section i4.11.5). Since the software submitted will be "command line executables"(section 4.4), our understanding is that the five seconds will include file I/O and WSQ decompression. Is this correct? See the answer to question 4 below about no longer requiring WSQ as input. The 5 seconds does still include reading the input file and writing the segmentation coordinates file. This timing allows the testing process to complete in a reasonable time frame. I will take out the "much less."

  4. I would like to request not to feed WSQ images so that slap segmentation technology is only evaluated, and processing time is shortened. Note: It takes approx. 1.4 seconds to decompress 1576x1572 pixel image using the NIST WSQ tool (NBIS) on 2.8GHz PC. This time is not negligible compared to the required time limit (much less than 5 sec). Only raw pixel data files will be used for input. All WSQ compressed data will be decompressed by NIST before being passed to the segmentation process.

  5. ssIIseg2 II means uppercase I like Idaho? Yes

  6. Are the options mandatory or not (i.e. image file name)? WSQ images are being removed as an input option. Processing the other input parameters is required.

  7. Maybe it would be good with -i option also to give version information of the program. Along with the email address the vendor can give version information that may be helpful if debugging is needed. Please put the email address first followed by version information.

  8. It is suggested that NIST to make sufficient number of "problematic 3-inch slap images with versatile characteristics" available to participants. Because "3-inch slap image" are not popularly used except US Federal agencies such as US-VISIT some participants would have hard time to access those data. It is also benefit for SlapSegII sponsors to have participants more chances to improve slap segmentation accuracy. The 3 inch data NIST is Sensitive But Unclassified/Government Use Only, so this data can't be distributed to the vendors.

  9. Can NIST publish the instructions/rules/criteria that were applied by human examiners to decide where each side of a segmentation box should be when they "hand corrected all errors"? Yes, I will try to add more information to section 5.1 of the testing plan documentation.

  10. Will the ground truth be provided for the sample data? It would help to have a better understanding of "a small amount of white space." What is the range for that “small amount of white space†in terms of pixels? Where should the bottom side of the segmentation box be placed if the "first joint/crease of the finger" is not clear? NIST will provide the ground truth with the sample data that will show the typical amount of white space. NIST will try to provide examples of difficult cases.

  11. In ground truth data, is the missing finger, if any, marked as "-1", the same as the software output for undetected/un-segmented finger defined in section 4.9? Yes

  12. Could you specify how the ground truth was produced on the 2-inch images? Especially were the experts instructed to set the same orientation for all 4 boxes? The same tool/criteria was used on 2-inch and 3-inch data with the one exception of allowing for rotated boxes on the 2-inch data. The rotation angle was the same for all 4 boxes in the 2-inch data.

  13. Can the sample size be expanded to track technological improvement? There is more data available for this purpose but would require hand marking the ground truth segmentation boxes.

  14. Is the criteria three or more fingers of 10 or three fingers from each slap? Since three or more fingers are proposed as a criteria, are thumbs considered in the NIST 96% error rate? The criteria was three or more from each slap. The 96% did not include thumbs.

  15. Is the measure of successful segmentation binary, being either "successful" or "failed"? Or is the measure a multi-value score, being variable over offsets of the four sides and angle in comparison with ground truth segmentation box (smaller offsets indicate a 'better' segmentation)? If the measure is binary, does 'successful segmentation' for 3 inch slap mean that ALL FOUR sides of the segmentation box are within tolerances specified in Fig 8 (section 6.1) in comparison with ground truth segmentation box (or -1 if the finger is missing)? If the measure is multi-value score, what is the formula for scoring? The measure is success or fail and success means all four sides are within the specified tolerances.

  16. It is stated that "If the segmentation algorithm can't detect/segment one or more of the fingers it must output a -1 after the finger number indicating it could not segment that finger" (section 4.9). So successful segmentation for missing finger should output -1. Is this correct? Yes

  17. Is the performance to be evaluated on finger basis or on subject basis? NIST intends to report multiple combinations of results that look at individual finger results as well as combinations of fingers for a subject.

  18. Is the performance to be measured by the percentage of successful segmentations? Does NIST intend to use any other scoring scheme such like those used in latent testing (ELFT07)? The performance will be percentage of successful segmentations but this will be reported for individual fingerprints as well as combinations of different fingers.

  19. If part of a finger is truncated, how is the segmentation box validated? For example on the right little finger on Figure 6, should the x-right and y-bottom values be inside the image or outside? The 3-inch ground truth boxes do not extend outside the boundaries but corners of the 2-inch boxes could extend beyond the image boundaries due to the fingerprints being rotated in the image.

  20. When the fingerprint has an unusual shape (e.g. fingertip or finger much narrower / shorter than usual), does the ground truth produce a box having the same unusual shape, or does it place the fingerprint into a larger box having more standard proportions? What are the min/max width/height of the rectangles in the ground truth? The ground truth box would have the same "unusual" size.

  21. Is there a penalty if a segmentation box is produced for a missing finger (i.e. is it considered as an error)? A missing finger should have a -1 returned as the segmentation coordinate otherwise it is considered an error.

  22. Regarding the possibility to use the 3-inch algorithm on the 2-inch data, how will the output file be handled? Will it be converted to vertical boxes with no rotation? No, the error function will take the reported rotation into consideration. The exact error function is still being developed/tested for the 2-inch data.

  23. "Other tolerances can be shown which would be useful for vendors to see where segmentation error may be occurring. This can include results given by individual edges, individual fingers, and left/right hand statistics in different finger combinations like 3 or more per hand and both index/middle". We recommend publishing as many of these as measures as possible. NIST is planning to report this type of information.

  24. We are opposed to the more liberal tolerance criteria for the bottom of the fingerprint bounding box. Accurate segmentation of fingertips from slaps should include crease detection, since this delineates the extent of the fingertip. In our opinion, the tolerances should not be loosened for evaluation purposes simply because some slap segmentors have difficulty with the process. If you want to include results for various levels of performance with respect to other tolerances, then do so, but compromising on crease tolerance simply because of its difficulty does not seem reasonable. In fact, this is precisely what should be evaluated. Furthermore, in the interest of interoperability, correct matching of fingerprints should not have to depend on the ability of a matcher to do segmentation, which is essentially what you are suggesting by stipulating that "most of the better matchers crop the input image". If your intent is to promote interoperability, this decision would seem to go against the grain of that philosophy. NIST is considering reporting the results for difference tolerances around the crease, as some applications would want to minimize the amount of data being transferred/stored/processed. The tolerances currently described in the draft testing plan are based on matching studies to determine what tolerances are acceptable with minimal effect on matcher accuracy.

*
Bookmark and Share