我尝试在我的桌面 Java 应用程序中使用 OpenCV Transparent API UMat 类进行硬件加速，但我找不到 UMat 类实现。我正在使用OpenCV version 4.1，其中T-API java 绑定据说从version 3.0 可用，如here 所说：
引入了T-API（透明API），这是透明GPU 使用 OpenCL 的加速层。它不添加任何编译时间或 OpenCL 的运行时依赖项。当 OpenCL 可用时，它会被检测到 并使用，但它可以在编译时或运行时禁用。它 涵盖约 100 个 OpenCV 函数。这项工作是按合同完成的 AMD 和英特尔公司的慷慨支持。
T-API 是否已弃用？如果是，用什么替代它？OpenCV Graph API G-API 是什么？它是 T-API 的替代品吗？【问题讨论】：
让我们分解这个问题。
T-API 是否已弃用？如果是，用什么代替它？
不，T-API 并未被有效弃用。你可以看到here，T-API 在 OpenCV 4.1.2 版本标签下仍然有效。 您的主要问题是 T-API 没有实际的 Java 包装器，因为我们可以看到 at this answer 并且在 @ 下看不到 UMat 实现987654323@.
顺便问一下，什么是 OpenCV Graph API G-API？它是 T-API 的替代品吗？
再次查看the docs，我们读到：
OpenCV 3.0 引入了透明 API（或 T-API），它允许将 OpenCV 函数调用透明地卸载到 OpenCL 设备，并使用 cv::UMat 保存主机/设备数据传输——这是向前迈出的一大步。然而，T-API 是一个动态 API——用户代码仍然不受约束，OpenCL 内核以任意顺序排队，从而消除了进一步的流水线级优化潜力。 G-API 为 OpenCV 4.0 带来了隐式图模型。图模型捕获管道中的所有操作及其数据依赖关系，从而为 G-API 框架提供额外信息以进行管道级优化。
据记载，G-API 似乎并不是“替代品”，而更像是对 OpenCV 硬件加速计划的改进。 G-API 不仅对无组织的内核进行了一些优化操作，还为较新版本的 OpenCV 带来了面向管道/图形的范例。
【讨论】：