问题标签 [ocr]

是否可以为某些Gumstix板上的Intel PXA270编译tesseract-ocr ？有没有人成功地做到了这一点，如果有，你是怎么做到的？

根据Wikipedia的说法，“拉丁文字、打字文本的准确识别现在被认为是在诸如扫描打印文档等清晰成像的应用中已基本解决的问题。” 但是，它没有给出引用。

我的问题是：这是真的吗？当前的最先进技术是否如此出色以至于 - 对于英文文本的良好扫描 - 没有任何重大改进需要改进？

或者，这个问题的一个不太主观的形式是：现代 OCR 系统在识别英文文本以进行高质量扫描方面的准确度如何？

这是一个艰难的：

我需要能够在屏幕上找到一个单词的位置和大小（它的框架）（它的第一次出现就足够了，从那里我应该能够得到下一个）。

例如，我希望能够检测（但不限于）Word、Excel 和 PowerPoint for Mac 以及 Safari 等中的单词位置。

解决方案应该尽可能快；我应该能够每秒找到至少 5-6 个单词并尽可能少地使用 CPU 时间。

到目前为止，这是我的想法：

• 窗口屏幕截图/图形上下文中的 OCR（任何适用于 Mac OS X 10.4 且可用于商业产品的优秀开源框架？）。Evernote 非常擅长识别图像中的单词。我不知道它是使用定制的内部引擎还是开源/商业引擎，但如果这是一个“有效”的解决方案，那将是我想要使用的引擎。理想情况下，我会在活动应用程序的窗口中检测到单词的框架（如何获取另一个应用程序的框架？）。
• 在 Quartz 的文本绘制上获得某种“钩子”，并在绘制时截取单词的位置（乍一看似乎不太可行！）。
• AppleScript，但这在很大程度上取决于应用程序提供的 API（我认为您无法从我所看到的 Word 文档中获取单词的坐标）而且速度很慢。
• ...没有想法...

我的目标是根据包含段落文本的字符串以正确的顺序获取段落中所有单词的框架。

提前感谢您的任何提示！

这不是真正的“OCR”，因为它不能识别字符，但它与应用于曲线的想法相同。任何人都知道用于从（光栅）绘图图像中检索值的图像处理库或已建立的算法？例如，在此图中，我很难用眼睛读取确切的值，因为网格线之间存在这样的差距：

我可以使用直尺或其他任何东西，但它仍然容易出错。如果有软件可以截取任何旧图并自动将其转换为值表或可以查询的函数，那就太好了。

好像叫“曲线识别”？也可用于从未公布基础数据的科学论文的曲线中提取数据。

并且可以有一些人工指导。例如，OCR 没有理由无法读取“100”并将其与线匹配，但是在机器提取曲线相对于网格线的路径后，让人类为线提供数值是可以的。我最感兴趣的是相对于网格跟踪曲线的功能，即使网格以非仿射方式倾斜、旋转或扭曲。

更新：

现在有一篇 Wikipedia 文章，名为将扫描的图形转换为数据，链接中有一堆软件。还有一些在alternativeto.net 上的软件。我猜这个理论现在属于http://dsp.stackexchange.com，而软件解决方案属于http://superuser.com？

我需要找出用户单击的图像中的单词。到目前为止，我已经成功地对图像进行了 OCR。我的 c# 应用程序中有一个图片框控件。用户可以在任何文本周围绘制一个框并将其拖动到文本框以填充文本框。我已经完成了这个。但是现在我有一个新要求，说用户可以选择一个文本框，然后单击图像中的一个单词，以便将该单词填充到文本框中。

我不知道如何进行。如何从图像中单独剪切单词部分并将其提供给 OCR。用户可以点击单词的任何部分。

请给我任何指示。我应该遵循什么算法来找到用户点击的单词的边界。如果我找到了边界，我可以使用 copyfromscreen 方法从图像中剪切它，并将其提供给 ocr 引擎以获取文本。

希望我在这里澄清了我的问题。

谢谢和问候，迪内什。

你能推荐一些用于OCR和手写字符识别的python库或源代码吗？

I'm wondering if there is some kind of way to do fuzzy string matching in PHP. Looking for a word in a long string, finding a potential match even if its mis-spelled; something that would find it if it was off by one character due to an OCR error.

I was thinking a regex generator might be able to do it. So given an input of "crazy" it would generate this regex:

It would then return all matches for that word or variations of that word.

How to build the generator: I would probably split the search string/word up into an array of characters and build the regex expression doing a foreach the newly created array replacing the key value (the position of the letter in the string) with ".+".

Is this a good way to do fuzzy text search or is there a better way? What about some kind of string comparison that gives me a score based on how close it is? I'm trying to see if some badly converted OCR text contains a word in short.

我正在开发一个应用程序，我必须在其中使用 OCR 引擎，请你帮我选择这方面最好的一个。我必须从图像中提取文本。

我听说过艾比。是最好的吗？？？？？？

建议是否有其他选择

提前谢谢

我正在寻找手写识别解决方案。我在这里找到了一个，它是一个 Flash 应用程序。它的工作原理是什么？它是否对 db 进行任何查询以查找字符？

I have to pull two pre-printed (not hand-written) fields out of a paper form, such that it can be automatically routed after being scanned. The fields contain batch and item identifiers, like "GG-9192" or "EPN/245G".

I've tried the following software:

• Tesseract-OCR
• Cuneiform
• Canon ImageRunner built-in OCR
• Asprise OCR Java API (demo)

I've tried the following settings:

• Scanning at resolutions of 300dpi and 600dpi
• Tried different fonts, including OCR-A and OCR-B.

In all cases output was pretty much all over the place. I can kick back documents for which I can't properly extract the necessary information, but I'm thinking it's going to be at least half of them. I considered some sort of fuzzy logic based on known values in a database, but sometimes these identifiers can differ by a single character, like "123G" and "123C".

Is this a lost cause? Perhaps OCR just isn't mature enough to handle a requirement of this nature? What other techniques might you recommend? Barcodes?

Edit: the containing application is in Java, so any recommendations for which there are free or cheap Java-based APIs for would help.

Edit 2: if anyone is interested...without any special tuning, Cuneiform for Linux and the Canon ImageRunner worked best, with Tesserect-OCR and Asprise Java API producing the worst results...none of the four was acceptable for anything but standard document search grade OCR. I'm beginning to think that this isn't going to work out.