I am trying to deploy my ImageGear Pro ActiveX project and am receiving an error stating
The module igPDF18a.ocx failed to load
when registering the igPDF18a.ocx component. Why is this occurring, and how can I register the component correctly?
To Register your igPDF18a.ocx component you will need to run the following command:
igPDF18a.ocx
regsvr32 igPDF18a.ocx
If you receive an error stating that the component failed to load, then that likely means that regsvr32 is not finding the necessary dependencies for the PDF component.
The first thing you will want to check is that you have the Microsoft Visual C++ 10.0 CRT (x86) installed on the machine. You can download this from Microsoft’s site here:
Microsoft Visual C++ 10.0 CRT (x86)
https://www.microsoft.com/en-us/download/details.aspx?id=5555
The next thing you will want to check for is the DL100*.dll files. These files should be included in the deployment package generated by the deployment packaging wizard if you included the PDF component when generating the dependencies. These files must be in the same folder as the igPDF18a.ocx component in order to register it.
DL100*.dll
With those dependencies, you should be able to register the PDF component with regsvr32 without issue.
regsvr32
During the installation of ImageGear for .NET (v23.4 and above), the installer reaches out to Microsoft’s site to download the VC++ redistributable and .NET packages. Which one(s) does it download?
The ImageGear for .NET installer places the following redistributables onto a system:
In addition to this, the following .NET framework versions are installed:
So, if a system already has all of these installed on it, this should prevent the installer from trying to reach out to download them.
For ImageGear .NET, what are the feature differences between an OCR Standard license, an OCR Plus license, and an OCR Asian license?
https://www.accusoft.com/products/imagegear/pricing/
ImageGear’s OCR library has three different functionality options that you can choose for your website or application. The primary difference between the three options is the output formats created by the OCR engine. The options for your development are as follows:
OCR Standard: The standard edition creates output formats for Western languages such as English. The standard edition outputs text only files and generates a PDF. The file formats it includes are searchable text PDFs and text documents.
OCR Plus: The standard plus edition creates formatted outputs for Western languages like English. The formatted output is created with recognition technology that identifies font detail, locates image zones, and recognizes table structure in order to create a representation of the original document. The file formats it includes are Word, Excel, HTML, searchable PDF, and text documents.
OCR Asian: The Asian edition creates a formatted output for Asian languages like Chinese, Japanese, and Korean. This formatted output is created with the same recognition technology as the Standard Plus that identifies font detail, locates image zones, and recognizes table structure. It also creates a representation of the original file. Formats include Word, Excel, HTML, searchable PDF, and text documents.
I encounter an Unhandled Exception error, as shown below, in ImageGear when trying to load a page into the recognition engine.
Error Message: An unhandled exception of type ‘ImageGear.Core.ImGearException’ occurred in ImageGear22.Core.dll Additional information: IMG_DPI_WARN (0x4C711): Non-supported resolution. Value1:0x4C711
Error Message: An unhandled exception of type ‘ImageGear.Core.ImGearException’ occurred in ImageGear22.Core.dll
Additional information: IMG_DPI_WARN (0x4C711): Non-supported resolution. Value1:0x4C711
What is causing this and how can I fix it?
This is probably because the original image used to create the page didn’t have a Resolution Unit set.
To fix this, check if the page has a Resolution Unit set. If it does not, set it to inches. You should also set the DPI of the image as those values were probably not carried over from the original image since the Resolution Unit wasn’t set. The following code demonstrates how to do this.
// Open file and load page. using (var inStream = new FileStream(@"C:\Path\To\InputImage.jpg", FileMode.Open, FileAccess.Read, FileShare.Read)) { // Load first page. ImGearPage igPage = ImGearFileFormats.LoadPage(inStream, firstPage); if (igPage.DIB.ImageResolution.Units == ImGearResolutionUnits.NO_ABS) { igPage.DIB.ImageResolution.Units = ImGearResolutionUnits.INCHES; igPage.DIB.ImageResolution.XNumerator = 300; igPage.DIB.ImageResolution.XDenominator = 1; igPage.DIB.ImageResolution.YNumerator = 300; igPage.DIB.ImageResolution.YDenominator = 1; } using (var outStream = new FileStream(@"C:\Path\To\OutputImage.jpg", FileMode.OpenOrCreate, FileAccess.ReadWrite)) { // Import the page into the recognition engine. using (ImGearRecPage recognitionPage = recognitionEngine.ImportPage((ImGearRasterPage)igPage)) { // Preprocess the page. recognitionPage.Image.Preprocess(); // Perform recognition. recognitionPage.Recognize(); // Write the page to the output file. recognitionEngine.OutputManager.DirectTextFormat = ImGearRecDirectTextFormat.SimpleText; recognitionEngine.OutputManager.WriteDirectText(recognitionPage, outStream); } } }
When using OCR in ImageGear .NET, is there any way to distinguish between a capital/uppercase letter O and the number 0?
Not without context or a font that makes the difference clear (such as one with a slashed 0). ImageGear will properly recognize Oliver and 1530 as containing O and 0, respectively, but cannot reliably distinguish it when letters and numbers are mixed. That is, ImageGear may not reliably distinguish between 1ABO0F3 and 1AB0OF3.
Is the main FormSuite for Invoices (FSI) process multithreaded? If so, would more cores or more CPU’s increase the performance?
Internally, we do multi-threading where we can at the beginning of the process. Improving your hardware will help if you are doing multiple pages at once, otherwise it will not. FormSuite for Invoices is thread-safe as long as each thread owns the FSI object being used.
Please see: https://help.accusoft.com/FSInvoices/v1.0/webframe.html#Operating%20Requirements.html
The logging for ImageGear C & C++ Deployment Packaging Wizard (DPW) is showing different output for some components since v19.3, why is this?
In ImageGear C & C++ v19.2 and prior, the DPW had additional logging information for the ARTX component in its deployment.log:
Deploying an application that uses the ARTXGUI library of ImageGear ARTX Component requires the following merge modules to be installed: Microsoft_VC90_CRT_x86_x64.msm Microsoft_VC90_MFC_x86_x64.msm
Deploying an application that uses the ARTXGUI library of ImageGear ARTX Component requires the following merge modules to be installed:
Microsoft_VC90_CRT_x86_x64.msm
Microsoft_VC90_MFC_x86_x64.msm
But since v19.3, the logs are no longer telling me to install these modules. Is this a mistake, or are they no longer necessary?
This was an intentional change on our end, and the Deployment Packaging Wizard (DPW) is working as intended. We made some updates to the DPW in the latest release; one update is that the CRM requirements for CORE (which is required in every project) now also covers the ARTX component. If the DPW is not saying you need additional components to use the ARTX component, then you’ll be fine.
I am trying to perform OCR on a PDF created from a scanned document. I need to rasterize the PDF page before importing the page into the recognition engine. When rasterizing the PDF page I want to set the bit depth of the generated page to be equal to the bit depth of the embedded image so I may use better compression methods for 1-bit and 8-bit images.
ImGearPDFPage.DIB.BitDepth will always return 24 for the bit depth of a PDF. Is there a way to detect the bit depth based on the PDF’s embedded content?
To do this:
ImGearPDFPage.GetContent()
ImGearPDEImage
ImGearPage
The code below demonstrates how to do detect the bit depth of a PDF page for all pages in a PDF document, perform OCR, and save the output while using compression.
private static void Recognize(ImGearRecognition engine, string sourceFile, ImGearPDFDocument doc) { using (ImGearPDFDocument outDoc = new ImGearPDFDocument()) { // Import pages foreach (ImGearPDFPage pdfPage in doc.Pages) { int highestBitDepth = 0; ImGearPDEContent pdeContent = pdfPage.GetContent(); int contentLength = pdeContent.ElementCount; for (int i = 0; i < contentLength; i++) { ImGearPDEElement el = pdeContent.GetElement(i); if (el is ImGearPDEImage) { //create an imGearPage from the embedded image and find its bit depth int bitDepth = (el as ImGearPDEImage).ToImGearPage().DIB.BitDepth; if (bitDepth > highestBitDepth) { highestBitDepth = bitDepth; } } } if(highestBitDepth == 0) { //if no images found in document or the images are embedded deeper in containers we set to a default bitDepth of 24 to be safe highestBitDepth = 24; } ImGearRasterPage rasterPage = pdfPage.Rasterize(highestBitDepth, 200, 200); using (ImGearRecPage recogPage = engine.ImportPage(rasterPage)) { recogPage.Image.Preprocess(); recogPage.Recognize(); ImGearRecPDFOutputOptions options = new ImGearRecPDFOutputOptions() { VisibleImage = true, VisibleText = false, OptimizeForPdfa = true, ImageCompression = ImGearCompressions.AUTO, UseUnicodeText = false }; recogPage.CreatePDFPage(outDoc, options); } } outDoc.SaveCompressed(sourceFile + ".result.pdf"); } }
For the compression type, I would recommend setting it to AUTO. AUTO will set the compression type depending on the image’s bit depth. The compression types that AUTO uses for each bit depth are:
Disclaimer: This may not work for all PDF documents due to some PDF’s structure. If you’re unfamiliar with how PDF content is structured, we have an explanation in our documentation. The above implementation of this only checks one layer into the PDF, so if there were containers that had images embedded in them, then it will not detect them. However, this should work for documents created by scanners, as the scanned image should be embedded in the first PDF layer. If you have more complex documents, you could write a recursive function that goes through the layers of the PDF to find the images. The above code will set the bit depth to 24 if it wasn’t able to detect any images in the first layer, just to be on the safe side.
Disclaimer: This may not work for all PDF documents due to some PDF’s structure. If you’re unfamiliar with how PDF content is structured, we have an explanation in our documentation. The above implementation of this only checks one layer into the PDF, so if there were containers that had images embedded in them, then it will not detect them.
However, this should work for documents created by scanners, as the scanned image should be embedded in the first PDF layer. If you have more complex documents, you could write a recursive function that goes through the layers of the PDF to find the images.
The above code will set the bit depth to 24 if it wasn’t able to detect any images in the first layer, just to be on the safe side.
In FormSuite for Invoices, what are the accepted characters for the Currency and CurrencyPlus field data types?
Note: FSI assumes that currency values are United States values. It normalizes fields that are marked as Currency (not CurrencyPlus), any punctuation (except negative and decimal).
Currency
CurrencyPlus
The Currency and CurrencyPlus formats are used in the FSI recognition to help determine currency values on the page.
The Currency value is of the form
dd¢
[$|€|£|¥]ddd[{separator}ddd][{decimal}dd][-|=][ €]
The CurrencyPlus value is of the form
[$|€|£|¥|E|EUR]ddd[{separator}ddd][{decimal}dd][-|=][ €| E|EUR|DKK|DKR|NOK|NKR|SEK|SK|GBP|KR|USD]
Where separator “,” and decimal “.” Or separator “.” and decimal “,”
In ImageGear .NET, I am receiving error “API_HARDTIMEOUT_ERR” when using Recognize() to OCR a document. What is happening and how can I fix it?
Sample case: I have a large PDF I was processing page-by-page. The first 15 pages took six minutes, but the 16th page took three minutes and produced that error.
API_HARDTIMEOUT_ERR can occur when ImageGear has taken too long to process your document. This tends to happen when the OCR process is spending too much time on things it thinks are characters (very common in bitonal documents), such as, scan artifacts in damaged documents, visual marks (e.g, the distortion of a camera picture of a computer monitor), or other marks that the recognition engine would waste time on because it thinks they’re letters. See the bottom of this page for an example.
API_HARDTIMEOUT_ERR
For scanned bitonal documents, running a Despeckle operation on the page can help reduce the amount of noise obstructing the OCR process.
ImGearRasterPage igRasterPage = p.Rasterize(1, 300, 300); if (ImGearRasterProcessing.Verifier.CanApplyDespeckle(igRasterPage)) ImGearRasterProcessing.Despeckle(igRasterPage, 3, 3);
Also, if converting documents to bitonal is part of the document process, ImageGear .NET has reducing methods that may make for a less damaged document, such as our Reduce method with configurable parameters. Alternately, the color document could be OCR’d instead with likely better results.
In the past, some users have found some success adjusting some of the time-based parameters in the recognition engine. ImGearRecTradeoff and DecompMethod can be modified to trade-off accuracy for speed during the actual OCR process, and Locate can be used to identify existing text before recognition.
ImageGear .NET v24.6 added support for viewing PDF documents with XFA content. I’m using v24.8, and upon trying to open an XFA PDF, I get a SEHException for some reason…
Why might this be happening?
One reason could be because you need to execute the following lines after initializing the PDF component, and prior to loading an XFA PDF:
// Allow opening of PDF documents that contain XFA form data. IImGearFormat pdfFormat = ImGearFileFormats.Filters.Get(ImGearFormats.PDF); pdfFormat.Parameters.GetByName("XFAAllowed").Value = true;
This will enable XFA PDFs to be opened by the ImageGear .NET toolkit.
In ImagXpress Professional ActiveX, I’m trying to place a fairly large amount of data into the TIFF tags of a multi-page TIFF image, and after processing several pages, ImagXpress throws a -1061 error from the FileSetTags method. What is the cause of this problem?
If you are using a version of ImagXpress earlier than 13.6.07, this can be caused by a known defect in the product, in which ImagXpress adds excessive amounts of padding to the file during the process of adding tags. This is normally not a problem, but with large files and large amounts of TIFF data, it can break.
The issue was resolved by the 13.6.07 hotfix for ImagXpress. This fix is also included in ImagXpress 13.7 or later – upgrading to that version will resolve your issue.