I just upgraded my Aspose.OCR-nuget-package from version 17.11.0 to 19.8.1, which broke the following code at “ocrEngine.Process()”:
Aspose.Pdf.License licPDF = new Aspose.Pdf.License();
licPDF.SetLicense("Aspose.Total.lic");
Aspose.Pdf.Document pdfDoc = null;
Aspose.OCR.License licOCR = new Aspose.OCR.License();
licOCR.SetLicense("Aspose.Total.lic");
Aspose.OCR.OcrEngine ocrEngine = new Aspose.OCR.OcrEngine();
using (var ms = new MemoryStream(File.ReadAllBytes(Path.Combine("pathToDocument", "Beispiel3.pdf"))))
{
pdfDoc = new Aspose.Pdf.Document(ms);
if (pdfDoc != null)
{
var sb = new StringBuilder();
foreach (var page in pdfDoc.Pages)
{
using (var imageStream = new MemoryStream())
{
var jpegDevice = new Aspose.Pdf.Devices.JpegDevice(new Aspose.Pdf.Devices.Resolution(300), 100);
jpegDevice.Process(page, imageStream);
imageStream.Position = 0;
ocrEngine.Image = Aspose.OCR.ImageStream.FromStream(imageStream, ImageStreamFormat.Jpg);
if (ocrEngine.Process())
{
Console.WriteLine(ocrEngine.Text);
}
}
}
}
}
The error states:
MyNamespace.UnitTest.AsposeTest_OCR_PDF_to_TXT.Test_AsposeOCR_PDFToText:
Aspose.OCR.OcrException : Error occurred during recognition.
----> System.IO.FileNotFoundException : The file "pathToMyProject\UnitTest\bin\Debug\data" does not exist.
StackTrace:
at Aspose.OCR.OcrEngine. ()
at Aspose.OCR.OcrEngine.Process()
at MyNamespace.UnitTest.AsposeTest_OCR_PDF_to_TXT.Test_AsposeOCR_PDFToText() in pathToMyProject\UnitTest\AsposeTest_OCR_PDF_to_TXT.cs: line 74.
--FileNotFoundException
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.GetAttributes(String path)
at .(String , String )
at .(IEnumerable`1 )
at ..ctor(IEnumerable`1 )
at ..ctor()
at ..ctor()
at ..ctor( , Boolean )
at .( , Boolean )
at Aspose.OCR.OcrEngine.()
Testing the nuget-version 19.8.0 replicates the same error.
Please find the pdf-file attached: Beispiel3.pdf (70.6 KB)
We have tested the scenario in our environment and were able to replicate the issue. We have logged it as OCR-797 in our issue tracking system for further investigation. We will look into details of the issue and keep you posted with the status of its correction. Please be patient and spare us little time.
We have recorded your concerns along with the logged issue and will definitely keep you posted on the status of its resolution. Please spare us a little time.
Is there any workaround for this? Any code sample on how to use a Build 19.9 Aspose.OCR successfully?
While M.Heinz is trying to OCR a PDF, I am trying to OCR image files such as JPG and PNG files. But it does the exact same thing as what M.Heinz is reporting; it’s coming up with the exact same error. Like M.Heinz my code works fine with Build 17.11, but I cannot find a way to make build 19.9 work at all. I note that it has already taken 2 months since M.Heinz reported this, and I would be very unpleasantly surprised if you had left a completely non-functional product in public release for that long. So I am assuming that this was released on the basis of it working in some scenarios, and it would be helpful if you could find some way of making the current software work… and share it with us poor unfortunates
Please accept our humble apologies for the inconvenience which has been faced. Please note that the issue is already being investigated and we are trying our best to resolve it as soon as possible. Further releases of the API have also been pending because of this scenario as this is taking time to get resolved.
We will definitely consider your concerns and will surely let you know as soon as we have some definite updates regarding resolution of the ticket or any available workaround. We greatly appreciate your patience and comprehension in this matter. Please spare us little time.
Iirc I also tried to OCR an image file, as this is an other application in our software - having the same issues. But having an identical error message and stack trace, I did assume the underlying issue to be the same and therefore didn’t think of reporting this issue as well.
We are in process to resolve this issue and hopefully we will be updating you soon about it fix. We really apologize for the inconvenience which has been faced.
Would you kindly try using Aspose.OCR for .NET 19.9.1. It is necessary that you try to build your application in x64 mode instead of AnyCPU. Currently we do not support AnyCPU or x86 architectures because we use specific CPU instruction sets that are not available in x86 mode. In case you still face any issue, please feel free to let us know.
First of all, I’m very disappointed about not beeing kept in the loop about the patch 19.9.1, which apparently dropped about 2 months ago and you just proposed as a possible solution to the issue - when you said, you’d be updating me about a fix.
Secondly, my application relies on beeing build in AnyCPU-mode; therefore x64 is not an option for my productive environment.
Regardless of any of the above: Using Aspose.OCR nuget-version 19.9.1 and building specifically in x64 does not resolve the issue, mentioned in the first post of this topic. None of the behavior did change in any way.
Please accept our humble apology for this. Please note that the proposed solution was just a workaround and was provided with the fix to another issue reported in a different thread. Whereas, the original issue linked with this forum thread is still unresolved and as we shared earlier, we will surely inform you as soon as it is resolved.
We have noted your concerns and feedback and will surely keep them in view during issue analysis and its resolution. We highly appreciate your patience and comprehension in this matter. Please spare us some time.
I’m back again to check on progress. As M.Heinz points out, build 19.9.1 does not resolve this problem.
I appreciate that this is a “free support forum”. I appreciate that software can always have a bug in it. Our own software is no different.
But this situation is.
This is not just some bug that manifests itself if one uses the software “just so”. Due to this bug, the software is unusable. It is literally impossible to use your OCR product because this error happens every time. There is no workaround.
What’s more, this does not appear to be anything that should be hard to track down. From looking at the error message it appears that this is nothing more difficult to figure out than a bit of Unit Testing code that was accidentally left behind in the application. How hard can it be, really, to track that down?
And here is the crux of the issue. We paid a LOT of money for Aspose Total. A LOT. And we expect it to work. We can accept the occasional bug, or the need to work around something that doesn’t quite work the way it should. That’s fine. But we cannot accept one component in your suite simply NOT WORKING. AT ALL.
At this stage I want to see some evidence that this issue has now been pushed up the queue for immediate attention, and that there will be a solution for it. Soon.
We humbly apologize for all the inconvenience that have been faced.
Please note that we do agree with all of your concerns and assure you that all of them would be taken care of as we are working over fixing the issue and plan to release the fixed assembly soon. Due to some other parallel tasks, any promising ETA cannot be shared at the moment however.
One of the main reasons is, issue does not occur in our development environment and it seems related to some specific configurations of IDEs and NuGet. The culprit ‘data’ folder that has Neural Network Weights, should be unpacked automatically while installing assembly from NuGet package.
One of the workarounds is to manually download package from NuGet and unpack it in your local system. Then copy ‘data’ folder into your project Debug directory. The ‘data’ folder exists in ‘contentFiles’ directory of the downloaded package. You can rename the package extension to .zip in order to unpack.
In some cases, above mentioned workaround would not work as well and changing the name of NN weights in ’ /bin/Debug/data’ folder form ‘lines_l2.json’ to ‘crnn_l2.json’ is required as hotfix.
Please note that all above mentioned findings indicate that we are working over fixing the issue and intend to provide a more stable version of the API. We have already raised the issue to next priority level. Due to parallel development in Aspose.OCR Cloud API, the resolution to this issue has been delayed unfortunately. But, we will surely provide an update soon.
We surely and highly appreciate your patience and cooperation in this matter. We again apologize for the inconvenience and delay.
@asad.ali thanks for the clarification. I understand that a 3rd (4th to us) party NuGet package is to blame for the problem. I hope the provider of this package has been alerted to the problem and they have committed to addressing it?
May I ask what NuGet Package, exactly, is at fault here?
We are surely in the process to address the issue and have recently published two packages over NuGet i.e. 19.9.2 and 19.9.3. It seems that the local cache of packages or assembly DLLs may somehow affect, in case of work in visual studio.
The NN Weights were introduced in 19.8 version of the API and relevant file was included in the package. It should be unpacked automatically in Debug folder the project which is not happening. We are testing the scenario with new uploaded packages and will share our feedback with you soon.
We will surely keep you posted as soon as we have additional updates regarding issue resolution. Meanwhile, as a workaround, you may please copy data folder and put it into Debug Directory in order to use API without any error.
We are working over releasing a new version of the Aspose.OCR for .NET which will include .NET Core support. The NN Weights unpacking would not be part of this release and the error under the discussion will be fixed in upcoming version. As soon as new version is released, we will inform you.
