【问题标题】:Kofax Capture Recognition - I vs 1Kofax Capture 识别 - I vs 1
【发布时间】:2013-01-24 20:09:21
【问题描述】:

使用 Kofax Capture 10(SP1、FP2),我在文档的某些字段上设置了识别区域。这些字段始终将 I 识别为 1。我已经尝试了所有我能想到的设置组合,它们不会抹去该字段中的所有字符,但无济于事。我尝试过 Advanced OCR 和 High Performance OCR,不同的字符过滤器。各种东西。

我可以尝试哪些选项来自动识别此字符?我应该告诉制作表格的人(它们是由计算机生成的)他们需要尝试使用不同的字体吗?说服他们现在是考虑使用验证的时候了?

我当前的字段设置:

Kofax Advanced OCR 没有自定义设置,除了高级对话框中的最大化准确度。这和我迄今为止尝试过的任何其他方法一样有效。

使用的字体是 8 - 12 pt arial,顺便说一句。

【问题讨论】:

  • 其他字母好像没有这个问题
  • 扫描分辨率是多少?
  • 我相信它是 200 dpi。导入的 PDF 文件只有 120 dpi,所以我没有浪费精力试图从中获得更多。
  • 对于成功的 OCR,分辨率非常低,我对您遇到问题并不感到惊讶!我想您在导入过程中使用 VRS 来尝试尽可能多地清理图像?
  • 只是常规的识别配置文件。他们似乎做得很合理。我想我只是不确定 VRS 还能做什么。也就是说,我们在一组特定的测试文件上的准确率高达 90% - 96%,而这只是一个真正无法支撑它的领域。 Kofax 支持甚至不认为我可以做更多的事情来增加它。我想我可以要求他们将 DPI 调高一点,也许到 300。

标签: ocr capture kofax


【解决方案1】:

如果涉及 OCR,则验证是必须,无论是处理电子文档还是纸质文档。对于纸质文档来说,这是一个更大的要求。

至少使用 11pt Arial 并将文档渲染为 300 dpi 图像。这会给你我说的 99.9% 的准确率(即每 1000 个错过的字符中有 1 个字符)。如果您的数据中数字和字母混合在一个单词中,尤其是 1-I、0-O、6-G,则准确性可能会下降。

如果您知道自己没有此类混合数据并且 OCR 仍返回混合的数字和字母,则可以使用识别脚本。您可以使用 PostRecognition 脚本事件从 OCR 引擎捕获识别结果,并使用 SBL 或 VB.NET 脚本对其进行修改。但这在很大程度上取决于您处理的文档和数据。

图像清理对电子文档没有任何好处。

我会说你最好使用验证。至少这会将责任推给验证操作员。

【讨论】:

  • 我同意可能应该进行验证,但客户想要“自动”并且显然无法腾出资源来每天验证数百个文档。我将继续并将其标记为答案,尽管我怀疑我是否能够让他们这样做,因为我们已经开始着手研究涉及使用 KIC-ED 导入 XML 的解决方案。
  • 正如我在另一个论坛上所写的那样,您的客户有不切实际的期望并且不了解技术。试着让他们知道 OCR 永远不会——我再说一遍:永远——无论你做什么,只要有足够的样本,就可以 100% 准确。这不是 Kofax 的问题,这是一个技术问题:无论他们选择哪种产品,都无法做到 100%。如果不是 100%,那么您需要有人查看数据。您可以通过在可能的情况下自动验证数据来加快速度。另一种解决方案是 XML,正如您所写的那样,它会给您带来更好的结果。
  • 我想说关于从电子文档识别中删除图像清理的建议对我来说比我得到的任何其他建议都更好。我在同一客户的另一个批次类中使用了这种技术,到目前为止它很棒。我很确定他们不会在 Kofax 培训中介绍这些信息,或者如果他们这样做了,我会在此期间忘记。
  • 图像清理更像是一门艺术而不是科学。根本问题在于它是 Catch 22:为了正确执行图像清理,您应该识别文档。但是为了识别文档,您必须已经执行了清理。由于没有“一刀切”的解决方案,因此您需要使用各种样本进行测试,调整设置并始终使用整个样本集重新测试,看看是否有更糟的情况。
  • 理想情况下,有数以百万计的文档需要数字化,必须手动验证数据?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多