Where can you see front scan result? US-DL

[YoonLee]

It seems like Delaware DL front scanning fails and resulting out documentDataMatch to be .failed.

I am using Microblink 5.15.2, and from the supported release note saying (https://github.com/BlinkID/blinkid-ios/blob/master/documentation/BlinkIDRecognizer.md) Delaware should be included. It may due to the front scanning distortion due to dark room or Delaware driver itself has lower densities or whatnot. If that was the case then it would failed out at the beginning.

Q1: Is there way to reveal the front scan result? I am able to access scanned back barcode and its data but can't find the front data. The class that I am using MBBlinkIdCombinedRecognizer to get MBBlinkIdCombinedRecognizerResult Q2: How to debug on this? Q3: Also, help me understand about the maxAllowedMismatchesPerField used for? When documentDataMatch mismatches, how else to find out which of datas being not matched?

[mparadina]

Hi @YoonLee

To answer your questions:

Q1: Yes, there is way to obtain the information specifically from the front side of the license. You would then need to use the frontVizResult method to check the front side information, while the barcodeResult on the backside (from the barcode). An example:

let result = self.blinkIdRecognizer?.result
let frontVizResult = result?.frontVizResult
let barcodeResult = result?.barcodeResult

let firstNameFront = frontVizResult?.firstName
let firstNameBack = barcodeResult?.firstName

Q2: This is the correct way of debugging this. For instance, you can compare the document number and dates (date of issue, date of expiry) to see if the information matches from the front VIZ (front side) and the barcode (backside).

Q3: The maxAllowedMismatchesPerField gives an 'option' to the SDK on how many mismatches can there be during the scanning session when the data match is active. By placing '1', there can only be one mismatch. For instance, when the SDK compares the information from the front and the backside and there is one mismatch (for example, it reads a '0' as an 'O' from the document number), the data match will still return .success as it was only one mismatch. Another way of checking the status of the last scanning process can be with processingStatus, with which you can check if the SDK had any difficulties with the scanning. For instance, it can give you information if the barcode was not properly extracted, or if there were any issues with the document fields.

Example:

let result = self.blinkIdRecognizer?.result
let processingStatus = result?.processingStatus

if processingStatus == .barcodeRecognitionFailed {
    print("Reading or parsing of the barcode has failed.")
} else if processingStatus == .fieldIdentificationFailed {
              print("Identification of the fields present on the document has failed.")
} else if processingStatus == .invalidCharactersFound {
              print("Result contains invalid characters in some of the fields.")
}

A question from my side, does the SDK always return failed with the Delaware licenses? Have you checked multiple licenses or just a particular one?

[YoonLee]

Thanks for the answering my questions. Yes, my associates having at least two Delaware license failure. I have tested on Microblink 5.15.0 and Microblink 5.15.2

[mparadina]

Hi @YoonLee

Do you maybe have any information regarding the environment in which the licenses have been scanned?

I'm asking this because sometimes external factors (glare, blur, device's camera quality) can influence the scanning process and cause the .failed response with data match. For instance, if the end-user is scanning the document from an area with low or very bright light sources, it can prevent the SDK from having a clear view of the document, causing OCR mistakes that result in a failed data match.

Did you maybe get a chance to see the results from the frontVizResult and the barcodeResult to see if the data is matching?

[YoonLee]

Our organization has a paid license, so I believe it has no issue unless US-DE driver's license is excluded. 

frontVizResult: It appears to have the following properties, with the format differing slightly from the barcode result.

• firstName: appears combined middle name whereas barcode has its own middleName property written on.
• lastName: same
• fullName: not appears whereas barcode one does
• address: same except for newline in each form and postal code includes dash (-)
• sex: abbreviation used(F) whereas barcode written non abbreviation ex) FEMALE
• dateOfBirth: same format but different MBDateResult instance address (expected)
• dateOfIssue: same format but different MBDateResult instance address (expected)
• dateOfExpiry: same format but different MBDateResult instance address (expected)
• documentNumber: same
• restrictions: same
• endorsements: same
• vehicleClass: same

Front OCR kicked in, but the result failed due to unmatch criteria. I wish there was a way to delegate return the diffs so I could measure the thresholds.

I compared it with my working condition DL, and the front and rear barcode results were similar to the failed one except for middleName. Do you think this is the case that OCR reads the first name only, but then the barcode result has a separate first and middle name? Some people have a middle name, but some people do not.

It looks like all Delaware DL fails more than 2. Can you verify this support issue? Thanks.

[mparadina]

Hi @YoonLee

Would you mind contacting us directly at support@microblink.com and share the license key that you're using in the project? We can inspect it on our end to see if all of the necessary rights are added.

[YoonLee]

Hi @mparadina,

I have sent an email to support@microblink.com and want to follow up with this. The subject should start with "Delaware License Scan". It looks like Github doesn't allow me to make this issue panel private. 

[mparadina]

Hi @YoonLee

We've received the email on our side and responded. Thank you for notifying us here!

[YoonLee]

Let's update this issue to private/close for now.