Join us for an engaging webinar, as we unravel the potential of AI for revolutionizing document management.
Watch Now
Enable your employees to remain productive throughout the document management process.
Read More
Learn how SmartZone uses a regular expression engine integrated into the recognition engine to achieve the best possible accuracy on data that can be defined by a regular expression.
Docubee is an intelligent contact automation platform built to help your team success
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.
Why do I get a “File Format Unrecognized” exception when trying to load a PDF document in ImageGear .NET?
You will need to set up your project to include PDF support if you want to work with PDF documents. Add a reference to ImageGear24.Formats.Pdf (if you’re using another version of ImageGear, make sure you’re adding the correct reference). Add the following line of code where you specify other resources:
ImageGear24.Formats.Pdf
using ImageGear.Formats.PDF;
Add the following lines of code before you begin working with PDFs:
ImGearFileFormats.Filters.Insert(0, ImGearPDF.CreatePDFFormat()); ImGearPDF.Initialize();
The documentation page linked here shows how to add PDF support to a project.
How do I use a Network Drive path for Image and ART storage in my ImageGear .NET web application?
In an ImageGear .NET web application, you have to define the location of the images and annotations directory in the storageRootPath and artStorageRootPath configuration property. In the current version of ImageGear .NET, the storageRootPath and artStorageRootPath do not work with a network drive path \\SERVER-NAME\sharefilename.
storageRootPath
artStorageRootPath
\\SERVER-NAME\sharefilename
The workaround for this would be to create a Symbolic link from a local directory to the network drive directory.
> mklink /d "local path" \\SERVER-NAME\sharefilename
web.config: storageRootPath="local path" artStorageRootPath="local path"
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 want to re-arrange the page order of a PDF. I’ve tried the following…
var page = imGearDocument.Pages[indx].Clone(); imGearDocument.Pages.RemoveAt(indx); //// Exception: "One or more pages are in use and could not be deleted." imGearDocument.Pages.Insert(newIndx, page);
But an exception is thrown. Somehow, even though the page was cloned, the exception states that the page can’t be removed because it’s still in use.
What am I doing wrong here?
If you’re using an older version of ImageGear .NET, you may run into this exception when you clone the page. Some of the resources between the original and the clone are still shared, which is why this happens.
Starting with ImageGear .NET v24.8, this no longer happens, and the above code should work fine.
If you still need to use the earlier version, you can use the InsertPages method instead.
InsertPages
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); } } }
How do I remove XMP Data from my image using ImageGear .NET?
When removing XMP data in ImageGear, the simplest way to do this is to set the XMP Metadata node to null, like so:
ImGearSimplifiedMetadata.Initialize(); doc.Metadata.XMP = new ImGearXMPMetadataRoot();
Or, you can traverse through the metadata tree and remove each node from the tree:
// Example code. Not thoroughly tested private static void RemoveXmp(ImGearMetadataTree tree) { ArrayList toRemove = new ArrayList(); foreach (ImGearMetadataNode node in tree.Children) { if (node is ImGearMetadataTree) RemoveXmp((ImGearMetadataTree)node); if (node.Format != ImGearMetadataFormats.XMP) continue; toRemove.Add(node); } foreach (ImGearMetadataNode node in toRemove) tree.Children.Remove(node); }
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 ImageGear, why am I running into AccessViolationExceptions when I run my application in parallel?
This issue can sometimes occur if ImGearPDF is being initialized earlier in the application. In order to use ImGearPDF in a multi-threaded program, it needs to be initialized on a per-thread basis. For example, if you have something like this:
ImGearPDF
ImGearPDF.Initialize(); Parallel.For(...) { // OCR code } ImGearPDF.Terminate();
Change it to this:
Parallel.For(...) { ImGearPDF.Initialize(); // OCR code ImGearPDF.Terminate(); }
The same logic applies to other ImageGear classes, such as ImGearPage instances or the ImGearRecognition class – you should create one instance of each class per thread, rather than creating a single instance and accessing it across threads. In the case of the ImGearRecognition class, you’ll have to use the createUnique parameter to make that possible e.g.:
ImGearPage
ImGearRecognition
createUnique
ImGearRecognition recEngine = ImGearRecognition(true);
instead of
ImGearRecognition recEngine = ImGearRecognition();