OCR plus engine failing on jpeg with incorrect metadata

We’ve recently moved to the Plus OCR engine and have encountered a problem when recognising JPGs with metadata that doesn’t match the actual image.
 
The X Resolution & Y Resolution tags report a resolution that differs from the actual image resolution, which I presume is used by Leadtools as a check, throwing an “Unsupported Resolution” exception.  It would be of great benefit to us if there was a way to get Leadtools to analyse the image itself rather than the metatags to determine compatibility.

Attached is an example of an image which causes the exception.


Thanks!

The post has no attachments. Please out the image in a ZIP or a RAR file and post it again without using the preview feature or send it to support@leadtools.com and mention this forum post.

If the ZIP/RAR file is larger than 5 MB, send an email to support@leadtools.com to give you the FTP upload instructions.

Here's the missing attachment.

The DPI is important to the OCR engine and is not merely secondary metadata.
I opened the image in MS Paint and saved it as BMP, and the resulting file also had a vertical resolution of 48462 dots per inch (DPI).
This means it's not only LEADTOOLS that reads the high DPI value, and image itself was saved with incorrect resolution.
Also, since the BMP format does not support Exif metadata, this clearly shows that the DPI itself is incorrect.

The solution in cases like this is to change the DPI value after loading the image in LEADTOOLS but before passing it to the OCR engine. This is done by a simple assignment to the XResolution and/or YResolution values of the bitmap in memory.

Actually BMP does store some metadata, in particular the resolution details, which is why, if you load the image with paint (which ignores it) you can see the image, but try with windows picture viewer, and you can see it stretched to the resolution defined in the header. Paint actually copies the exif metadata and stores it in it's own header format

http://en.wikipedia.org/wiki/BMP_file_format#Bitmap_Information_.28DIB_header.29

I've attached a snapshot of the BMP header file hex code that shows the matching values in the location specified in the wiki definition from a BMP converted by paint to the exif output on the original jpeg.

Using xnview (excellent & free image browser) - you can see it analyses the image itself, ignoring the BMP metadata and produces the correct resolution. We were hoping Leadtools would be able to do something similar to determine resolution compatibility as our clients use a vast array of image types, so analysing and repairing the metadata for each possible type of image isn't a small task and tackling the problem by using the raw image data would potentially fix all types with a single change.

Thanks again,

Andrew Bonds
_______________________
Iris Data Services

Andrew,

Yes, the BMP format (and many other formats) can store DPI in their headers and I did not write that it doesn't. I wrote that "the BMP format does not support Exif metadata" to explain that the OCR engine cares about the DPI, which is an important part of the image information, but does not care about other metadata, such as 'secondary' information supported by the Exif format.

Our toolkit has the ability to display the image in screen pixels and ignore the very high value of the X resolution. For example, if you open the image in our main C# demo and do not enable the "Use DPI" option, the image will look like the attached screenshot.
However, the OCR engine cannot be made to ignore the bad DPI value. If you want to send an image to the OCR engine, you must do any analysis and DPI changes needed before you pass it to the OCR functions.

You previously wrote that "The X Resolution & Y Resolution tags report a resolution that differs from the actual image resolution".
My question to you is how exactly do you determine the actual image resolution if it's not a number stored in the file itself? If we clearly define the answer to this question, implementing it with LEADTOOLS should be very easy.
One thing you could do is to automatically detect for cases where the values don't make sense. You could use LEADTOOLS to check the X and Y resolution values and isolate all images that appear suspicious. For example if the X resolution value is very different from the Y resolution. Or if the 2 values are close to each other but outside the acceptable range for OCR (for example lower than 100 or higher than 600 DPI).

If you need more details on how to do that, please tell me which LEADTOOLS version (16, 17, etc.) and programming interface (.NET classes, DLL API, C++ Classes, etc.) you are using.

Basel,

the actual image resolution is stored in the file, not the "X Resolution" and "Y Resolution" tags which define DPI in , but in pixel "Width" and "Height". If you remove the X/Y Resolution tags, OCR works just fine, defaulting to the width and height tags, proving the dpi tags redundant, We were hoping you guys could adjust the OCR engine itself to use the pixel width/height tags instead? It seems a little odd to be using an optional block of metadata to determine engine compatibility rather than the physical image geometry info.

We process terrabytes of data per day, and throughput is a large issue for us, so while it's possible to strip the DPI tagging info, this would be another performance hit and why we were hoping to avoid any image manipulation but just send it straight through to the engine.

Cheers,

Andrew

Andrew,
The pixel width and height of the image is only called 'resolution' in certain contexts, such as when talking about a device's capabilities (e.g. high resolution phone screen).

When it comes to imaging and OCR, the word 'resolution' means (pixels per unit length), such as dots per inch or dots per centimeter.
The pixel width and height are better called (image size), not (resolution).

In LEADTOOLS every image must have DPI resolution values. If the values are stored in the file, whether correct or not, LEADTOOLS will read these values.

If no DPI values are stored in the file, 2 things will happen automatically:
1. The flag value FILEINFO_NO_RESOLUTION will be turned on in the FILEINFO structure's Flags member. (Or something similar in programming interfaces other than C/C++).
2. An 'artificial' default value of 150 Dots Per Inch will be filled for both the X and Y resolution values.

This means deleting the DPI values is not a 'magical' solution. It is merely equivalent to setting them to 150 yourself, which is a special case of the solution I already suggested (check the values and correct them if they're wrong).

However, I would not recommend simply setting the DPI to 150 for ALL images, because for some images, a correct DPI value could increase the accuracy of OCR results.

Keep in mind that the check I'm suggesting is very quick and should take a very small fraction of the time needed to perform OCR.
You will NOT need to modify the tags in physical files. It will be a simple modification to your existing code that looks something like this:
... The code that loads the image ...
////////////// Add the following check
if (Bitmap.XResolution < MinValue) OR (Bitmap.XResolution > MaxValue) then Bitmap.XResolution = SomeReasonableValue
if (Bitmap.YResolution < MinValue) OR (Bitmap.YResolution > MaxValue) then Bitmap.YResolution = SomeReasonableValue
////////////// End of added check
... The code that passes the image to the OCR engine...

OK Basel,

Looks like preprocessing the images is unavoidable,

Thanks very much for your help with this issue,

Andrew