Atalasoft MobileImage SDK 评测

识别技术是定制化解决方案，这意味着它们大多在幕后运行。但如果没有它们，我们一些最喜欢和有用的现代应用程序将毫无价值。你手机上友好的语音助手——语音识别，大多数生产力工具中的搜索功能——光学字符识别 (OCR)，以及你最喜欢的在线商店中内容的自动组织——自然语言处理 (NLP)。在这篇文章中，我将解释高质量图像对于我正在开发的一个支持 OCR 和 NLP 的应用程序来说是如何最重要的元素。以及我是如何使用 MobileImage SDK 来实现这一点的。

由于我在识别技术方面有着深厚的背景，我的一个客户就如何最好地利用图像处理、OCR 和 NLP 来实现他们的快速记录收集应用程序向我寻求建议。他们需要通过移动应用程序，快速捕获图像，获得尽可能准确的 OCR 结果，然后根据 NLP 引擎返回的实体对文档进行逻辑分组。

最终目标是根据关键关键词改进数据导航，而无需手动组织。手动组织不可行的原因是数据更新速度非常快（几小时内），因此消耗速度越快越好。

为什么图像处理很重要——而且并非都一样

我确信你听说过“垃圾进，垃圾出”这句话。无论它多么陈词滥调，当涉及到这些技术时，捕获的早期阶段直接影响最终输出的质量。而这类应用程序中最重要的第一步是获取高质量的图像供 OCR 引擎处理。

我不是一个狂热的移动开发者，但我知道如何围绕利用图像 API 的最佳方式制定策略。并为我的客户提供正确的图像处理实现，以便他们在此基础上进行开发。我决定使用 Atalasoft 的移动图像 SDK。我早在多年前构建一个用于发票处理的 .NET 图像应用程序时就熟悉这个引擎。

在捕获图像方面，有数千种可能的文件类型、颜色深度、分辨率、裁剪、倾斜、降噪等组合。市面上存在基于消费者的图像 API，但它们在文档图像处理和企业级质量结果方面缺乏经验。

我花了一段时间才开始使用 SDK。但一旦我搭好框架，并进行了一些基本操作，比如拍照、处理照片，它就变得非常快。Atalasoft 的所有神奇之处都发生在用户点击“处理图像”按钮时。

实现

首先，我运行了 `kfxKEDQuickAnalysisFeedback` 方法，以获取图像质量的一些基本信息。最重要的是 isBlurry，如果为 true，我将强制用户捕获另一张图像。抖动是 OCR 的一大敌人。其他方面，如饱和度，是可以容忍的，因为双色调转换阈值通常可以很好地处理它。最糟糕的情况是反转，这仍然是可 OCR 的。

有了好的拍摄，我就可以进行进一步的图像处理来提高质量。为了获得最佳 OCR 结果，理想设置是：

• 格式： TIFF Group 4 - MIMETYPE_TIF

  前两个 OCR 引擎总是处理 TIFF Group 4 图像。如果你不转换它，引擎也会转换。因此，根据你对图像的了解，预先控制转换将产生更好的质量，并提高处理速度，因为 OCR 引擎不需要浪费时间进行转换。另外，TIFF 可以无损，这也很关键。

• 颜色： 黑白 KEDOutputColor{ KED_BITDEPTH_BITONAL=1}

  在原始彩色图像中，通过将其转换为黑白图像来识别文档是最佳方法。由于处理的输出结果比图像本身更重要，OCR 在双色调图像上效果最佳，因此我们宁愿牺牲美观而追求质量。

• 分辨率： 300 DPI

  300 DPI 是质量和速度的最佳组合。在更高质量下它更准确，但图像的发送速度会减慢，OCR 也会减慢。而低于 300 DPI 会迅速损失准确性。然而，在移动设备上，这是一个棘手的问题，因为手机摄像头决定了原始 DPI。因此必须进行转换。而且只有在裁剪后才能进行转换。转换有风险，但可以在设备上准确完成。

• 裁剪： KEDCroppingOptions{KED_CROP_AUTO}

  你能够减少图像并让目光聚焦在内容上的越多，性能和准确性就越好。我惊喜地发现 Atalasoft 的自动裁剪非常准确。由于移动捕获的性质，无法指定裁剪，而且让用户进行裁剪会太慢。因此，如果没有好的自动裁剪，我就无法使用裁剪功能。

所有基本的图像设置都可以使用内置类和枚举器完成。我还使用了 `kfxKEDImagePerfectionProfile` 来引用一个包含更高级设置的 XML 文件，其中包括分辨率更改、降噪、平滑和基于内容的倾斜校正。

由于图像的性质，操作顺序很重要

颜色 > 格式 > 裁剪 > 和 分辨率 > 清理 （在高级配置文件中）

我使用 API 的重点是图像处理。他们也有自己的捕获控制器。我决定不使用它，以防应用程序捕获图像的方式发生变化，并将捕获与处理隔离。

所有这些好东西之后，图像就会被发送到我搭建好的基于云的 OCR 服务器。OCR 之所以要在云端完成，是因为 OCR 非常耗费 CPU，我需要强大的处理能力才能在合理的时间内处理大量数据。不过，我的下一步是在基于云的 OCR 之前实现条形码读取。在某些情况下，这将完全避免 OCR 的需要。

MobileImage SDK 支持此功能，并且准确度非常好。它几乎可以在任何位置、任何角度读取条形码。我还会添加图像引导。对于移动设备上的图像来说，最困难的事情之一是摄像头的角度。如果它不完全平坦，将影响裁剪和文本质量。SDK 中的倾斜功能可以稍微帮助解决这个问题，但最好的办法是给用户一个矩形引导。

从用户的角度来看，他们只需做这些。结果由 OCR 服务器处理，然后根据使用 NLP 引擎找到的实体（人物、地点、专有名称等）进行存储和组织。之后即可用于发现目的。

MobileImage SDK 在高质量输出图像方面表现出色。我认为他们可以在提高易用性和 SDK 架构方面做得更好，而不是在处理方面。

• API 设计、类名、结构、枚举器等都很奇特。你真的需要了解（为他们工作）或者花费大量时间弄清楚每个元素的作用。命名约定和组织方式不太好。尤其是对于我这种编码方式，我不会提前阅读文档，而是使用代码补全来找到我需要的东西。
• 我希望文档能有所帮助。文档只能在 API 的分发包中找到。所以你必须在本地启动它。我希望它能支持所有元素的搜索，托管在他们的网站上，并提供更好的代码片段。
• 最后，我喜欢示例，最好的学习方式就是通过观察。但是我收到的一个代码示例将所有功能都集中在一个地方，并且不太好。主要是因为所有基本功能都被塞进一个应用程序中，而且注释也不好。我发现最好是在较小的应用程序中查看具体的用户流程。

但我明白所有这些本质上都是现有成熟客户端服务器 SDK 的移植产物，因此从这个角度来看是说得通的。而且 Xcode 也不那么容易使用，事后看来我应该使用 Xamarin 作为 IDE。当我最初开始这个项目时，我曾想尝试使用 SWIFT，但我无法使其工作。

无论如何，我的应用程序非常简单，所以一个 iOS Objective-C 项目就可以了。他们也支持 Android，我猜在那里使用会更容易一些。

一旦我开始，一切都不那么困难了。最重要的是解决了“无垃圾输入”问题。在测试了 30 张图像后，我可以证明我的 OCR 准确性以及最终的组织准确性约为 90%。这 10% 的下降并非由于图像处理（图像拒绝率仅为 5%），而是由于 OCR 准确性，最后是 NLP，它是所有技术中准确性最低的。

对于任何严肃的图像处理，以及任何不仅仅是面向消费者且需要一致性和强大图像支持的应用程序，我都会推荐 MobileImage SDK，而非更简单的图像 SDK。