Reduce false positive by considering minutia type during pair matching?

[martin0258]

Hello, many thanks for your work! It's very interesting to read/understand the algorithm.

I would like to understand why you choose not to consider minutia type during pairing? If a pair has different minutia type (e.g., probe=>ending, candidate=>bifurcation), I personally think it's not a supporting event or pair that tells us it might be the same point from the same finger. After all, if the minuta type is different, it is more likely that they are not the same point from the same finger.

I understand after pairing you have designed scoring Scoring.java to check if each pair has the same minutia type and assign more scores if more pairs have the same type, but it seems to be only a small portion of the total score. We may get high scores if minutia types are different for all pairs (0 from minutiaTypeScore but still positive scores for other scoring part)?

        for (int i = 0; i < pairing.count; ++i) {
            MinutiaPair pair = pairing.tree[i];
            score.supportingEdgeSum += pair.supportingEdges;
            if (pair.supportingEdges >= Parameters.MIN_SUPPORTING_EDGES)
                ++score.supportedMinutiaCount;
            if (pminutiae[pair.probe].type == cminutiae[pair.candidate].type)
                ++score.minutiaTypeHits;
        }
        score.minutiaTypeScore = Parameters.MINUTIA_TYPE_SCORE * score.minutiaTypeHits; 

Not sure if I understand your algorithm correctly, but I'm thinking maybe it would be better to consider minutia type during the pairing phase (e.g., pairing must have the same minutia type), or assign some penatly score if minutia types do not match, to further reduce false positive match? Or maybe you designed this way for the case where minutia types are different but the pair is still meaningful for a true positive match?

[robertvazan]

The trouble with minutia type is that it is unreliable. When you press your finger down, many endings touch neighboring ridge and start looking like bifurcations. Similarly, lighter pressure will turn many bifurcations into endings. Plus some minutiae are truly ambiguous - they turn towards nearby ridge but they don't quite touch it. Whether they end up looking like endings or bifurcations to the algorithm depends on how the image is smoothed.

[martin0258]

@robertvazan Thank you for the clarification!

1. I want to ensure I understand correctly. When you say, "Plus some minutiae are truly ambiguous—they turn towards a nearby ridge but don't quite touch it," are you indicating that some minutiae may resemble bifurcations (as they turn towards a nearby ridge) but might not actually be true bifurcations (because they are close to the ridge but do not actually make contact)?

2. If the algorithm could accurately determine that both the probe and candidate fingerprints were collected under similar pressure conditions (or if this assumption holds true for my dataset), would the minutiae types become more consistent and reliable across both images?

[robertvazan]

Yes, bifurcations and endings can both look like the other one under some circumstances. And yes, normalizing ridge thickness helps, but no, it is not enough. Equalization in SourceAFIS improves ridge thickness consistency, but minutia type is still often ambiguous. Even humans cannot always tell the difference.

You should view pairing as a recall-optimized algorithm. The goal is to collect as many likely pairs as possible. Scoring then evaluates how much evidence can be gathered from these pairs.

[martin0258]

@robertvazan Your explanation is clear. Thanks!

I have one additional question: Since pairing is a recall-optimized algorithm, would it be possible to allow users to adjust the extent of attempts to recall all pairs? I don't quite understsand if it's already brute-force. If it's not, if users are willing to wait longer for enhanced recall (hoping to get more pairs), is there a way to make this tunable within your algorithm?

[robertvazan]

Algorithm parameters are already tuned for maximum accuracy. You could argue about various aspects of the tuning, but accuracy was definitely the only goal during tuning.

[martin0258]

@robertvazan Thank you for your response. This issue could be closed 👍