3

我需要从 Java 应用程序服务器调用 tesseract OCR（它是 C++ 中的一个开源库，用于进行光学字符识别）。现在很容易使用 Runtime.exec() 运行可执行文件。基本逻辑是

  1. 将当前保存在内存中的图像保存到文件（.tif）
  2. 将图像文件名传递给 tesseract 命令行程序。
  3. 使用 FileReader 从 Java 读取输出文本文件。

通过为 Tesseract 编写 JNI 包装器，我可能会在性能方面获得多少改进？不幸的是，没有在 Linux 中工作的开源 JNI 包装器。我必须自己做，并且想知道收益是否值得开发成本。

4

3 回答 3

4

很难说这是否值得。如果您假设如果通过 JNI 在进程内完成，OCR 代码可以直接访问图像数据而无需将其写入文件，那么它肯定会消除那里的任何磁盘 I/O 限制。

我建议使用更简单的方法，并且仅在性能不可接受时才采用 JNI 选项。至少那时您将能够进行一些基准测试并估计您可能能够实现的性能提升。

于 2009-01-23T05:29:56.487 回答
4

如果您确实追求自己的包装器，我建议您查看JNA。它将允许您调用大多数仅编写 Java 代码的“本机”库，并且比原始 JNI 为您提供更多帮助以安全地执行此操作。JNA 适用于大多数平台。

于 2009-01-23T07:07:00.427 回答
1

我同意tweakt。如果没有性能原因，请不要使用 JNI。如果您使用 JNI 调用，如果您的 JNI 层或 OCR 本身存在一些内存泄漏甚至崩溃的可能性，您的应用程序稳定性也可能处于危险之中。如果您通过命令行界面使用它，则永远不会发生这种情况（所有内存将在程序退出时释放，并且可以在调用者代码中检查所有异常程序终止）。

于 2009-01-23T06:28:58.287 回答