11–20 of 48 posts
It doesn't appear that you can use this in a 'normal' .NET app. Any ideas why?
Can confirm that the actual package successfully installs into a Profile78 Portable Class Library. So whilst the marketing heavily mentions Windows Phone, in theory this library will also work on Xamarin (iOS/Android, etc) and also within standard .NET applications (ASP.NET/Console/etc). nb: haven't actually tested past installation at this stage. edit: nope :(
Earlier quoted context omitted.
Can confirm that the actual package successfully installs into a Profile78 Portable Class Library. So whilst the marketing heavily mentions Windows Phone, in theory this library will also work on Xamarin (iOS/Android, etc) and also within standard .NET applications (ASP.NET/Console/etc). nb: haven't actually tested past installation at this stage. edit: nope :(
Ah excellent, will try that, thanks!
It doesn't appear that you can use this in a 'normal' .NET app. Any ideas why?
I made a C# Console app and added the nuget package. It adds, but there aren't any references. Within the nuget package, though, there is are three subdirectories within 'lib', one being 'win81'. packages\Microsoft.Windows.Ocr.1.0.0\lib\win81 Within this, there are 'ARM' 'x86' and 'x64' directories and dlls within them. VS refuses to add them to my project, so I'm guessing they're native and not COM libraries. Why wo…
When calling native code outside the CLR the runtime needs to know which type of marshaling code to generate.
It also plays a role when using unsafe code blocks in .NET.
Off topic, but this made me think that it would be neat if libraries on places like github and nuget could someout include "cited by" data. Something that referenced open source (maybe closed source too) projects that had a dependency to the library similar to google scholar or CiteSeerX.
You can get a DOI for github.
is this better than the terrassect OCR?
"demonstrated in code snippets below". The code snippets are actually images and even worse, they're JPEGs which is the reason why the text looks horrible.
We had great results using tesseract-ocr[1] with SWT (state of the art text detection algorithm, via libccv[2]) on Linux. You can use our python bindings for both[3,4], although they might be slightly outdated: [1] https://code.google.com/p/tesseract-ocr/ [2] http://libccv.org/doc/doc-swt/ [3] https://github.com/veezio/pytesseract [4] https://github.com/veezio/pyccv
"demonstrated in code snippets below". The code snippets are actually images and even worse, they're JPEGs which is the reason why the text looks horrible.
We had great results using tesseract-ocr[1] with SWT (state of the art text detection algorithm, via libccv[2]) on Linux. You can use our python bindings for both[3,4], although they might be slightly outdated: [1] https://code.google.com/p/tesseract-ocr/ [2] http://libccv.org/doc/doc-swt/ [3] https://github.com/veezio/pytesseract [4] https://github.com/veezio/pyccv
Is it still possible to generate pixel correct hOCR when using SWT? Also, what is the main advantage of SWT - improving speed or accuracy?