在现代应用中，语音识别、光学字符识别（OCR）和自然语言处理（NLP）等技术为提供了极大的便利。没有这些技术，许多喜爱的应用将失去其价值。例如，手机上的语音助手、大多数生产力工具中的搜索功能，以及最喜欢的在线商店内容的自动组织。在本文中，将解释高质量成像对于正在开发的一个应用的重要性，该应用旨在支持OCR和NLP。将介绍如何使用MobileImage SDK来实现这一目标。
由于在识别技术方面有深厚的背景，一位客户向咨询了如何最好地利用成像、OCR和NLP技术来快速收集记录。他们需要通过移动应用快速捕获图像，尽可能准确地进行OCR处理，然后通过NLP引擎返回的实体逻辑地分组文档。最终目标是基于关键词汇改善数据导航，而无需手动组织。手动组织不是一个选项，因为数据很快就会过时（在几小时内），因此越快消费数据越好。
为什么成像很重要——并非所有成像都一样。可能听说过“垃圾进，垃圾出”的说法。无论这个说法多么陈词滥调，当涉及到这些技术时，捕获的早期阶段直接影响最终输出的质量。在这类应用的任何阶段，获取高质量图像供OCR引擎处理是最关键的第一步。
虽然不是一个狂热的移动开发者，但足够了解如何围绕最佳利用成像API的策略，并为客户提供适当的成像实现，以便他们在此基础上构建。决定使用Atalasoft的移动成像SDK。这是一个多年前在构建.NET成像应用程序用于发票处理时熟悉的引擎。
在捕获图像方面，有成千上万种可能的组合，包括文件类型、色深、分辨率、裁剪、倾斜、去噪等。市面上有一些面向消费者的成像API，但它们没有文档成像的经验，也无法提供企业级质量的结果。
开始使用SDK花了一段时间。但一旦搭建了框架，并进行了一些基本操作，比如拍照、处理照片，它就变得非常快。当用户点击“处理图像”按钮时，Atalasoft的所有魔法就发生了。
首先，运行了kfxKEDQuickAnalysisFeedback方法，以获取有关图像质量的一些基本信息。最重要的是是否模糊，如果是，会强制用户重新捕获图像。抖动对OCR来说是一个很大的敌人。其他方面，如饱和度，是可以容忍的，因为二值化转换阈值通常可以很好地处理这个问题。最坏的情况是反转，但仍然是OCR可识别的。
有了一个好的快照，就可以进行进一步的图像处理以提高质量。为了获得最佳的OCR结果，理想的设置是： 格式：TIFF Group 4 - MIMETYPE_TIF 顶级OCR引擎总是在TIFF Group 4图像上进行处理。如果不转换它，引擎会。因此，根据对图像的了解，提前控制转换会产生更好的质量，并提高处理速度，因为OCR引擎不需要浪费时间进行转换。此外，TIFF可以无损，这也是至关重要的。
颜色：B&W 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，怀疑那里的使用要容易一些。