cv::filter2d是opencv中最易用且高效的二维卷积接口，自动加速、支持same模式，但需注意核中心对齐、数据类型匹配及边界处理限制。
用 cv::filter2D 做图像卷积最省事
OpenCV 的 cv::filter2D 是 C++ 里最快上手、也最不容易出错的二维卷积接口，尤其适合图像处理这种固定尺寸、连续内存的场景。它底层自动调用 SIMD 或 OpenCL 加速（取决于编译选项），比手写三重循环快一个数量级以上。
常见错误现象：cv::filter2D 输出图像尺寸和输入一致，默认不补零，但如果你传入的卷积核（kernel）是奇数尺寸（如 3×3），中心对齐才合理；若为偶数（如 2×2），OpenCV 会把左上角当“中心”，结果偏移，图像边缘明显错位。
- 确保
kernel类型是CV_32F或CV_64F，输入图像类型需匹配（比如CV_8UC3输入要先转成浮点再卷积，否则溢出截断） - 用
anchor = cv::Point(-1, -1)让 OpenCV 自动选核中心（仅当核宽高都为奇数时有效） - 如果需要 valid 卷积（不补零、输出更小），得自己用
cv::getRectSubPix截取，cv::filter2D本身只支持 same 模式
手写循环卷积前先确认是否真需要它
纯 C++ 手写二维卷积（三层 for）在现代 CPU 上很容易成为性能瓶颈，尤其对大图或实时场景。除非你明确要：自定义边界填充策略（比如镜像延拓）、动态核更新、或嵌入无 OpenCV 环境（如裸机 DSP），否则不建议从零实现。
容易踩的坑：i + kx 和 j + ky 下标越界检查放错位置——放在内层循环里每次迭代都判断，开销极大；应提前计算有效区域范围，外层限定 i、j 范围，内层直接访存。
立即学习“C++免费学习笔记（深入）”；
- 用
std::vector<:vector>></:vector>存图？别这么做。缓存不友好，指针跳转慢。坚持用一维std::vector<float></float>+ 行优先索引：idx = i * width + j - 卷积核翻转问题：数学定义要 flip kernel，但 OpenCV 和大多数图像库默认输入的是已翻转核（即相关运算）。你给
cv::filter2D的kernel就是“相关核”，不是原始卷积核 - 编译加
-O2 -march=native，否则连基础循环都跑不满流水线
std::valarray 或 xtensor 能简化表达但不提速
有人想用 std::valarray 写卷积表达式图，或者引入 xtensor 做广播运算。语法确实简洁，比如 output(i, j) = (kernel * patch).sum()，但实际运行时多数情况比 cv::filter2D 慢 2–5 倍——因为缺少图像特有的内存访问优化（如 tile 分块、cache line 对齐）和硬件加速路径。
使用场景有限：仅适合小图（
-
xtensor需显式调用xt::eval()强制计算，否则只是构建表达式树，调试时容易误以为“没执行” -
std::valarray的shift和cshift不支持二维，得靠slice拆解，代码反而更绕 - 所有这类库对
uint8_t图像支持弱，强制转 float 中间存储，内存带宽压力翻倍
FFT 卷积只在大核时值得考虑
当卷积核尺寸超过约 32×32，FFT 方法（如用 FFTW 或 OpenCV 的 dft）才可能比空间域快。但要注意：它要求输入补零到 2 的幂次尺寸，且整个流程包含正向 DFT → 逐点乘 → 逆 DFT → 截取，实际延迟更高，不适合单帧小图。
性能陷阱：OpenCV 的 cv::dft 默认不启用 IPP 或 FFTW 后端，即使你编译时链接了，也要手动调 cv::setUseOptimized(true) 并确认 cv::useOptimized() 返回 true；否则就是纯 C 实现，比手写循环还慢。
- 别对每个像素单独 FFT——必须整图 batch 处理。小图做 FFT 反而因 O(N² log N) 复杂度拖垮性能
- 实数输入要用
cv::DFT_REAL_OUTPUT，否则默认复数输出，内存和计算浪费一半 - 输出需用
cv::idft后再取.rowRange(0, src.rows).colRange(0, src.cols)截回原尺寸，漏这步会得到全尺寸频域重构结果
真正难的不是选哪个函数，而是搞清你的核尺寸、图像大小、实时性要求这三者的组合关系。3×3 锐化？cv::filter2D 一行搞定。512×512 医学图像配准用 64×64 高斯核？这时候才该打开 FFTW 文档。其余时候，少造轮子，多看 cv::getBuildInformation() 输出里有没有 IPP/AVX/OpenCL 支持。
