- 操作系统：ubuntu22.04
- OpenCV版本：OpenCV4.9
- IDE:Visual Studio Code
- 编程语言：C++11
算法描述
G-API 背后的核心理念是可移植性——使用 G-API 构建的流水线必须是可移植的（或者至少具备可移植的能力）。这意味着，当为新平台编译时，它要么可以直接运行，要么 G-API 提供必要的工具以确保其在该平台上运行，而算法本身几乎不需要修改。
这一理念通过将内核接口与其具体实现分离来实现。一旦使用内核接口构建了流水线，它就变得与实现无关——实现细节（即使用哪些内核）是在单独的阶段（图编译）中传递的。
内核-实现层次结构可能如下所示：
流水线表达与内核定义
一个流水线本身只能用诸如A、B等术语来表达，而选择使用哪种实现则成为一个外部参数。
定义一个内核
G-API 提供了一个宏 G_TYPED_KERNEL() 来定义一个新的内核接口：
#include <opencv2/gapi.hpp>
G_TYPED_KERNEL(GFilter2D,
<cv::GMat(cv::GMat,int,cv::Mat,cv::Point,double,int,cv::Scalar)>,
"org.opencv.imgproc.filters.filter2D")
{
static cv::GMatDesc // outMeta's return value type
outMeta(cv::GMatDesc in , // descriptor of input GMat
int ddepth , // depth parameter
cv::Mat /* coeffs */, // (unused)
cv::Point /* anchor */, // (unused)
double /* scale */, // (unused)
int /* border */, // (unused)
cv::Scalar /* bvalue */ ) // (unused)
{
return in.withDepth(ddepth);
}
};
这个宏是定义新类型的一个快捷方式。它需要三个参数来注册一个新的类型，并且要求类型体必须存在（见下文）。宏的参数包括：
- 内核接口名称 – 同时作为使用此宏定义的新类型的名称；
- 内核签名 – 类似于 std::function<> 的签名，用于定义内核的API；
- 内核的唯一名称 – 当系统中内核的类型信息被移除时用于识别内核。
内核声明可以看作函数声明——在这两种情况下，新实体都必须根据其定义的方式来使用。
内核签名定义了内核的使用语法——即在图构建期间它接受哪些参数。实现也可以使用这个签名将其转换为特定后端的回调签名（参见下一章）。
内核可以接受任何类型的值，而G-API动态类型（如cv::GMat）有特殊的处理方式。所有其他类型对G-API来说是不透明的，在outMeta()或执行回调中按原样传递。
内核的返回值 只能是G-API动态类型——即cv::GMat、cv::GScalar或cv::GArray。如果一个操作有多个输出，应该将其包装在一个std::tuple<>中（该元组只能包含上述提到的G-API类型）。不支持任意数量的输出操作。
一旦定义了一个内核，就可以在流水线中使用由G-API提供的特殊方法"::on()"。这种方法具有与内核定义相同的签名，因此这段代码：
cv::GMat in;
cv::GMat out = GFilter2D::on(/* GMat */ in,
/* int */ -1,
/* Mat */ conv_kernel_mat,
/* Point */ cv::Point(-1,-1),
/* double */ 0.,
/* int */ cv::BORDER_DEFAULT,
/* Scalar */ cv::Scalar(0));
是一个完全合法的构造方式。然而，这个例子有些冗长，因此通常内核声明会附带一个C++函数包装器（“工厂方法”），以启用可选参数、更紧凑的语法、Doxygen注释等：
cv::GMat filter2D(cv::GMat in,
int ddepth,
cv::Mat k,
cv::Point anchor = cv::Point(-1,-1),
double scale = 0.,
int border = cv::BORDER_DEFAULT,
cv::Scalar bval = cv::Scalar(0))
{
return GFilter2D::on(in, ddepth, k, anchor, scale, border, bval);
}
因此，现在它可以像这样使用：
cv::GMat in;
cv::GMat out = filter2D(in, -1, conv_kernel_mat);
额外信息
在当前版本中，内核声明体（大括号内的所有内容）必须包含一个静态函数 outMeta()。此函数建立了操作输入和输出元数据之间的功能依赖关系。
元数据是关于内核操作的数据的信息。由于非G-API类型对G-API来说是不透明的，G-API只关心G* 数据描述符（例如cv::GMat的尺寸和格式等）。
outMeta()也是如何将内核签名转换为派生回调的一个例子——请注意，在这个例子中，outMeta()的签名严格遵循内核签名（在宏中定义），但有所不同——内核期望的是cv::GMat，而outMeta()接收并返回的是cv::GMatDesc（这是G-API结构体，用于cv::GMat的元数据）。
outMeta()的目的在于从输入到输出传播元数据信息，并推断内部（中间、临时）数据对象的元数据。这些信息对于进一步的流水线优化、内存分配以及G-API框架在图编译期间执行的其他操作是必需的。
实现一个内核
一旦内核被声明，其接口可以用于在不同的后端实现该内核的版本。这一概念自然地映射自面向对象编程中的“接口/实现”模式：一个接口可以被多次实现，并且内核的不同实现应该能够相互替换而不破坏算法（流水线）逻辑（里氏替换原则）。
每个后端定义了自己实现内核接口的方式。尽管如此，无论插件是什么，它的内核实现必须从内核接口类型“派生”。
然后，内核实现被组织成内核包。内核包作为编译参数传递给 cv::GComputation::compile()，并提供一些关于如何选择适当的内核的提示给G-API（更多内容见“异构性”[TBD]）。
例如，前述的Filter2D在“参考”CPU（OpenCV）插件中这样实现（注意——这是一个简化形式，不正确的边界处理）：
#include <opencv2/gapi/cpu/gcpukernel.hpp> // GAPI_OCV_KERNEL()
#include <opencv2/imgproc.hpp> // cv::filter2D()
GAPI_OCV_KERNEL(GCPUFilter2D, GFilter2D)
{
static void
run(const cv::Mat &in, // in - derived from GMat
const int ddepth, // opaque (passed as-is)
const cv::Mat &k, // opaque (passed as-is)
const cv::Point &anchor, // opaque (passed as-is)
const double delta, // opaque (passed as-is)
const int border, // opaque (passed as-is)
const cv::Scalar &, // opaque (passed as-is)
cv::Mat &out) // out - derived from GMat (retval)
{
cv::filter2D(in, out, ddepth, k, anchor, delta, border);
}
};
注意CPU（OpenCV）插件是如何转换原始内核签名的：
- 输入 cv::GMat 被替换为 cv::Mat，后者持有底层OpenCV函数调用的实际输入数据；
- 输出 cv::GMat 被转换为额外的输出参数，因此 GCPUFilter2D::run() 比原始内核签名多接受一个参数。
这里对内核开发者的基本直觉是不要关心 cv::Mat 对象是从哪里来的，而不是原来的 cv::GMat——只需遵循插件定义的签名约定。G-API将在执行期间调用此方法，并提供所有必要的信息（并将原始的不透明数据按原样转发）。
复合内核
有时，内核在API层面上是一个单一的事物。这对用户来说很方便，但在特定的实现层面，可能最好有多个内核（子图）来完成这个任务。一个例子是goodFeaturesToTrack()——虽然在OpenCV后端中它可以保持为一个单一的内核，但在Fluid中它变成了复合的——Fluid可以处理Harris响应计算，但不能执行稀疏非极大值抑制和点提取到STL向量：
复合内核的实现可以使用通用宏GAPI_COMPOUND_KERNEL()来定义：
#include <opencv2/gapi/gcompoundkernel.hpp> // GAPI_COMPOUND_KERNEL()
using PointArray2f = cv::GArray<cv::Point2f>;
G_TYPED_KERNEL(HarrisCorners,
<PointArray2f(cv::GMat,int,double,double,int,double)>,
"org.opencv.imgproc.harris_corner")
{
static cv::GArrayDesc outMeta(const cv::GMatDesc &,
int,
double,
double,
int,
double)
{
// No special metadata for arrays in G-API (yet)
return cv::empty_array_desc();
}
};
// Define Fluid-backend-local kernels which form GoodFeatures
G_TYPED_KERNEL(HarrisResponse,
<cv::GMat(cv::GMat,double,int,double)>,
"org.opencv.fluid.harris_response")
{
static cv::GMatDesc outMeta(const cv::GMatDesc &in,
double,
int,
double)
{
return in.withType(CV_32F, 1);
}
};
G_TYPED_KERNEL(ArrayNMS,
<PointArray2f(cv::GMat,int,double)>,
"org.opencv.cpu.nms_array")
{
static cv::GArrayDesc outMeta(const cv::GMatDesc &,
int,
double)
{
return cv::empty_array_desc();
}
};
GAPI_COMPOUND_KERNEL(GFluidHarrisCorners, HarrisCorners)
{
static PointArray2f
expand(cv::GMat in,
int maxCorners,
double quality,
double minDist,
int blockSize,
double k)
{
cv::GMat response = HarrisResponse::on(in, quality, blockSize, k);
return ArrayNMS::on(response, maxCorners, minDist);
}
};
// Then implement HarrisResponse as Fluid kernel and NMSresponse
// as a generic (OpenCV) kernel
重要的是要区分复合内核与G-API的高阶函数，即一个看起来像内核但实际上生成子图的C++函数。核心区别在于，复合内核是实现细节，内核实现可以是复合的，也可以不是（取决于后端的能力），而高阶函数在G-API中相当于一种“宏”，因此不能充当一个需要由后端实现的接口。