高级设计概述 OpenCV v4.8.0

G-API 高级设计概述

G-API 是一个异构框架，它提供了一个统一的应用程序接口，用于使用多个受支持的后端对图像处理管道进行编程。

其主要设计理念是保持管道代码本身的平台中立性，同时在图形编译（配置）时使用额外参数指定要使用的内核和设备。这一要求促成了以下架构：

• G-API 框架结构

该架构分为三层：

• 应用程序接口层（API Layer）–这是顶层，它实现了 G-API 的公共接口、构件和语义。当用户使用 G-API 构建管道时，他直接与这一层交互，用户操作的实体（如 cv::GMat 或 cv::GComputation）由这一层提供。
• 图形编译器层–这是一个中间层，它将用户计算展开为图形，然后对其进行一系列转换（如优化）。该层建立在 ADE 框架 之上。
• 后端层（Backends Layer）–这是最底层，列出了许多后端（Backends）。与上述两层相比，后端与底层平台细节高度耦合，每个后端代表每个平台。后端对经过处理的图形（来自图形编译器）进行操作，并针对特定平台或设备优化执行该图形。

应用程序接口层

API 层是用户在定义和使用管道（G-API 术语中的计算）时与之交互的部分。API 层定义了一组 G-API 动态对象，可用作图形中的输入、输出和中间数据对象：

• cv::GMat
• cv::GScalar
• cv::GArray（模板类）

API 层指定了在这些数据对象上定义的操作列表，即所谓的内核。有关 G-API 默认提供哪些操作的详细信息，请参阅 G-API core 和 imgproc 命名空间。

G-API 并不局限于这些操作，用户可以使用特殊宏 **G_TYPED_KERNEL()**轻松定义自己的内核。

此外，API 层还负责在管道创建时 marshalling 和存储操作参数。除了前面提到的 G-API 动态对象外，操作还可能接受任意参数（更多信息请点击 此处 ），因此 API 层会在执行时捕获其值并在内部存储。

最后，cv::GComputation 和 cv::GCompiled 是 API 层的其余重要组件。前者将一系列 G-API 表达式封装成对象（图形），后者是图形编译的产物（详见**本章**）。

图形编译层

每个 G-API 计算在执行前都要进行编译。编译过程有两种触发方式：

• 隐式，当使用 cv::GComputation::apply() 时。在这种情况下，图形编译后会立即执行。
• 显式，当使用 cv::GComputation::compile() 时。在这种情况下，会返回一个 cv::GCompiled 对象，然后可以作为 C++ 函数调用。

第一种方法推荐用于事先不知道输入数据格式的情况，例如输入数据来自任意输入文件。第二种方法推荐用于部署（生产）场景，在这种场景中，输入数据的特性通常是预定义的。

图形编译过程建立在 ADE 框架之上。最初，根据 API 层捕获的表达式生成一个双方图。该图包含两种类型的节点： 数据和操作。图总是以数据节点开始和结束，中间是操作节点。每个操作节点都有输入和输出，两者都是数据节点。

在生成初始图形后，实际上要对其进行一系列图形转换处理，这些转换称为传递。ADE Framework 是一个编译器通行证管理引擎，通行证是专门为 G-API 编写的。

不同的通行证可以检查图的有效性、完善操作和数据的细节、根据亲和性或用户指定的区域划分将节点组织成集群（“Islands”）[TBD]等等。后端还可以在编译过程中注入后端特定的传递，详情请参见**专门章节**。

图编译的结果是一个编译对象，由类 cv::GCompiled 表示。无论是否有显式或隐式编译请求，都会创建一个新的 cv::GCompiled 对象（见上文）。实际图形执行发生在 cv::GCompiled 中，由参与图形编译的后端决定。

另请参见

cv::GComputation::apply(), cv::GComputation::compile(), cv::GCompiled

后端层

上图列出了两个后端：OpenCV 和 Fluid。OpenCV 是所谓的 “参考后端”，它使用普通的 OpenCV 函数实现 G-API 操作。该后端适用于在熟悉的开发系统上进行原型开发。Fluid 是在 CPU 上高效执行缓存的插件，它采用不同的执行策略，并使用自己的特殊内核运行。在 CPU 上运行时，Fluid 后端可以实现更少的内存占用和更好的内存定位。

可能还有更多可用的后端，如 Halide、OpenCL 等。- G-API 提供了统一的内部 API 来开发后端，因此任何爱好者或公司都可以在新的平台或加速器上自由扩展 G-API。就 OpenCV 基础设施而言，每一个新的后端都是一个新的独特的 OpenCV 模块，在作为 OpenCV 的一部分构建时会扩展 G-API。

图形执行

图形的执行方式由选择用于编译的后端定义。事实上，在生成可执行（编译）对象时，每个后端都会在图形编译过程的最后阶段构建自己的执行脚本。例如，在 OpenCV 后端，该脚本只是要调用的 OpenCV 函数的拓扑排序序列；对于 Fluid 后端，它也是类似的东西–在每次迭代中处理输入行的代理的拓扑排序列表。

图形执行有两种触发方式：

• 通过 cv::GComputation::apply()，根据给定的输入数据就地编译图形；
• 通过 cv::GCompiled::operator()()，此时图形已被预编译。

这两种方法都是多态的，可接受不同数量的参数，并在运行时进行有效性检查。如果传递的数据对象的数量、形状和格式与预期的不同，运行时就会出现异常。G-API 还提供了类型包装器，将这些检查转移到编译时进行–请参见 cv::GComputationT<>。

G-API 图形执行被声明为无状态–这意味着编译后的函数（cv::GCompiled）就像纯 C++ 函数一样，为相同的输入参数集提供相同的结果。

两种执行方法都需要 N+M 个参数，其中 N 是输入的数量，M 是输出的数量，cv::GComputation 就是在这两个参数上定义的。请注意，虽然在定义中使用了 G-API 类型（cv::GMat 等），但执行方法接受 OpenCV 的传统数据类型（如 cv::Mat），这些类型可保存实际数据–请参阅 参数编组 中的表格。

另请参见

实现细节, 内核 API