引言
Monica(github.com/fengzhizi71…) 是我正在开发的一款跨平台图像编辑器。在 Monica 中，调色功能是最常用的核心模块之一，它支持对图像的色相、饱和度、亮度、高光、阴影、锐化、暗角、色温等多个参数进行灵活调节。
调色本质上是对每个像素的局部调整，虽然逻辑不复杂，但在处理高分辨率图像或进行频繁交互时，对性能的要求极高。
这个模块最初我使用了 OpenCV 的forEach()实现 HSL 空间下的像素遍历，虽然在功能上已基本完整，但随着 Monica 支持更高分辨率的图像输入，操作的流畅度明显下降，性能瓶颈逐渐显现。
为了提升响应速度，我开始对这套逻辑进行重构优化：
- 尝试使用
ptr()手动遍历像素替换forEach()使用 OpenCV 的parallel_for_()提升并发性能引入查找表（LUT）优化色彩调整计算第一阶段：功能实现（forEach + 原始逻辑）
在调色功能的最初实现中，我采用的是的思路：将图像转换为 HSL 空间后，使用 OpenCV 的 forEach 遍历每个像素，对每个通道进行逐一调整。这种方式的优点是代码简洁、逻辑直观、开发效率高，而且对于中小尺寸图片，性能尚可接受。
OpenCV 的Mat::forEach是一个较为现代化的 API，它可以对图像中的每个元素执行 lambda 函数操作，隐藏了繁琐的指针逻辑，并具备一定的自动并行能力（如果启用了 OpenMP/TBB 支持）。对于快速迭代开发来说，这种方式非常友好。
我早期的代码类似这样:
typedef cv::Point3_<uint8_t> Pixel; ...... _cachedHSLImg.forEach<Pixel>([&](Pixel &p, const int * position) -> void { int i = position[0]; int j = position[1]; auto hslVal = hslCopy.at<cv::Vec3b>(i,j); int hVal = hslVal[0] + _hueOffset; while (hVal > 180) { hVal -= 180; } int sval = hslVal[1] + _saturationOffset; if (sval > 255) { sval = 255; } if (sval < 0) { sval = 0; } unsigned char highlightFactor = highlightMask.at<unsigned char>(i, j); unsigned char shadowFactor = shadowMask.at<unsigned char>(i, j); int lval = _contractScale * hslVal[2] + _lightnessOffset + highlightFactor / 255.0 * _highlightOffset + shadowFactor / 255.0 * _shadowOffset; if (lval > 255) { lval = 255; } if (lval < 0) { lval = 0; } // 简单的暗角效果 float distanceToCenter = sqrt(pow(i - middleRow, 2) + pow(j - middleCol, 2)); float cornerFactor = 1.0 - std::max(distanceToCenter / radius * 2.0 - 1.0, 0.0) * _cornerOffset; lval *= cornerFactor; hslCopy.at<cv::Vec3b>(i,j) = cv::Vec3b{(unsigned char)hVal, (unsigned char)sval, (unsigned char)lval}; });在调色功能开发完成后，我对几张不同尺寸图像进行了初步测试。在 Release 模式下，处理一张常规分辨率（如 2048x1365）的照片，forEach 的表现是可以接受的（~400ms 左右）；但在高分辨率图像（如 3264x4928）下，性能开始成为问题，每一次处理都会超过 1 秒。这在实时编辑场景中，是不能接受的。
所以，接下来我需要想办法提升处理速度，同时又能保持调色效果不变。
第二阶段：效果保持前提下的优化尝试
第一版调色功能虽然逻辑清晰，但随着图像尺寸提升，forEach带来的性能瓶颈开始显现。为了提升整体响应速度，同时不改变现有的效果，我决定开始对内部处理逻辑进行优化尝试。
尝试用ptr<T>()替换forEach
ptr<T>()是 OpenCV 中一种更接近底层的访问方式，可以直接访问图像的逐行像素指针。理论上，它能减少函数调用开销、消除 lambda 包装，并在手动处理循环时带来更大的灵活性。
于是，我将原来依赖 forEach() 的 HSL 调整逻辑改写成如下形式：
for (int i = 0; i < rows; ++i) { cv::Vec3b* row = hslCopy.ptr<cv::Vec3b>(i); for (int j = 0; j < cols; ++j) { auto& hsl = row[j]; ... }}在 Release 模式下，使用ptr<T>()测试下来，针对小图确实有性能提升，但是针对大图并没有什么提升甚至有时候还比原来慢。
因为
forEach()会自动启用多线程（取决于 OpenCV 编译配置和平台），其性能并不一定差。
第三阶段：并行处理与数据复用
在上一阶段的优化提升幅度有限，且整体逻辑仍然是串行处理，每一行图像只能逐行遍历。那接下来考虑的方向是：进一步释放多核计算资源，提高处理吞吐量，同时避免不必要的重复计算。
3.1 引入 OpenCV 的 parallel_for_
OpenCV 内置了cv::parallel_for_()接口，能够在不引入 OpenMP 或 TBB 的前提下，快速实现多线程加速。
我对调色流程中的核心部分进行了并行封装，包括：
- HSL 通道的像素调整高光 & 阴影掩码的生成过程暗角（Vignette）距离计算色温处理（RGB 通道 LUT 查表）
示例代码如下：
parallel_for_(Range(0, rows), [&](const Range& range) { for (int i = range.start; i < range.end; i++) { Vec3b* row = hslImage.ptr<Vec3b>(i); ... }});在实际使用中，我观察到：
- 图像越大，
parallel_for_()带来的提速越明显在 macOS（CLang）和 Linux 下都表现良好无需显式依赖 OpenMP 或 TBB，部署更方便3.2 重复计算的“缓存与复用”
之前的调色流程中，有几个非常耗时的逻辑每次都重新计算，比如：
- 暗角效果：涉及每个像素到中心点的欧几里得距离开方高光/阴影掩码：每次调色都重新灰度转换 + mask 插值模糊图像：用于加权锐化，也会重复调用 GaussianBlur。
于是我将这些操作改为一次性预处理，仅在构造函数中生成：
// 预生成模糊图像GaussianBlur(origin, blurMask, Size(0, 0), 5);// 预计算距离平方图（用于暗角优化）parallel_for_(...);优化后，这些中间变量都在类内缓存，只要原图不变，就无需再次计算，大幅降低了后续 adjust() 的运行负担。
这一阶段的优化获得了明显的提升，原先高分辨率图像（如 3264x4928）一次调色大约需要1秒多现在优化到 600-700ms，至少比单纯使用forEach()要好很多。这使得调色功能足以支撑高分辨率图像的多次交互式调整。
接下来，还将进一步挖掘可预处理的逻辑，把逐像素的浮点计算，转变为查表操作——引入 LUT 进行全面替代运算。
第四阶段：引入 LUT 表优化
4.1 哪些通道适合 LUT 优化？
尽管在前一阶段通过并行化和数据复用大幅缩短了图像调色的耗时，但从代码中仍然可以看到存在一些热点计算逻辑，它们的特点是：
- 运算逻辑简单（如加法、乘法）调用频率极高（像素级别，每帧数百万次）
于是我开始思考一个经典的图像处理优化策略：能否将这些重复计算转化为查表操作（LUT：Look-Up Table）？
通过分析，最终决定对以下几个通道进行 LUT 优化：
| 调整项 | 通道 | 原始操作 | 是否适合用 LUT | 原因 |
|---|---|---|---|---|
| 色相 hue | H | 加法 + 环绕 | Y | 有规律，范围固定（0~180） |
| 饱和度 saturation | S | 加法 + 钳制 | Y | 简单线性操作 |
| 亮度 lightness | L | 线性缩放 + 偏移 + 钳制 | Y | 计算重复度高 |
| 色温 temperature | R/G/B | 乘法缩放 | Y | 针对 3 个通道，浮点乘法高频 |
| 高光 / 阴影 | L | 动态 mask 加权 | N | 与每张图的亮度图有关，需逐像素计算 |
| 暗角 | L | 基于距离的动态调整 | N | 需要用 mask 缓存，非固定变换 |
最终确定：H、S、L、R、G、B 六个通道全部 LUT 化，其余保留原始逻辑或使用 mask 替代。
4.2 LUT 的实现逻辑
在 OpenCV 中，我们可以使用cv::LUT()函数高效地将查表应用到图像的单通道或三通道矩阵中。查表的过程本质是：
dst(x, y) = LUT[src(x, y)]4.2.1 色相 H 通道 LUT
色相调整需要考虑色轮的环绕，例如：原值为 170，调整 +20 后应该变成 10 而不是 190。因此，不能直接使用 % 180，而应采用下面的方式处理负值和溢出：
lutH.create(1, 256, CV_8U);for (int i = 0; i < 256; i++) { int h = i + _hueOffset; h = (h % 180 + 180) % 180; // 确保值始终在 [0,180) lutH.at<uchar>(i) = static_cast<uchar>(h);}4.2.2 饱和度 / 亮度 通道 LUT
饱和度和亮度都需要线性加减，并钳制到 [0, 255] 范围，构建非常直接：
// 饱和度lutS.create(1, 256, CV_8U);for (int i = 0; i < 256; i++) { int s = i + _saturationOffset; s = std::clamp(s, 0, 255); lutS.at<uchar>(i) = static_cast<uchar>(s);}// 亮度（含对比度缩放 + 偏移）lutL.create(1, 256, CV_8U);for (int i = 0; i < 256; i++) { float l = _contractScale * i + _lightnessOffset; lutL.at<uchar>(i) = saturate_cast<uchar>(l); // 自动钳制}4.2.3 色温 RGB 通道 LUT
色温调整不同于简单加减，而是通道乘法。考虑到每次调色仅温度变化，其他通道应保持不变，因此我们单独构建 R/G/B 三张 LUT：
lutB.create(1, 256, CV_8U);lutG.create(1, 256, CV_8U);lutR.create(1, 256, CV_8U);if (_temperatureScale > 0) { for (int i = 0; i < 256; i++) { lutR.at<uchar>(i) = saturate_cast<uchar>(i * (1.0f + _temperatureScale)); lutG.at<uchar>(i) = saturate_cast<uchar>(i * (1.0f + _temperatureScale * 0.4f)); lutB.at<uchar>(i) = i; }} else { float scale = -_temperatureScale; for (int i = 0; i < 256; i++) { lutB.at<uchar>(i) = saturate_cast<uchar>(i * (1.0f + scale)); lutG.at<uchar>(i) = i; lutR.at<uchar>(i) = i; }}4.2.4 查表的使用方式
一旦 LUT 构建完毕，实际使用非常简单，OpenCV 内部会自动并行化并使用 SIMD：
// 对 H/S/L 通道查表LUT(hslChannels[0], lutH, hslChannels[0]);LUT(hslChannels[1], lutS, hslChannels[1]);LUT(hslChannels[2], lutL, hslChannels[2]);// 对 BGR 通道查表（色温）LUT(bgrChannels[0], lutB, bgrChannels[0]);LUT(bgrChannels[1], lutG, bgrChannels[1]);LUT(bgrChannels[2], lutR, bgrChannels[2]);这一阶段的六通道全 LUT 化的设计，在保持图像处理质量的同时，显著提升了处理速度。原先高分辨率图像（如 3264x4928）一次调色的时间也降到大约 400ms 左右。
400ms 是我使用的老款的 Intel 芯片的 MacBook Pro 进行测试的结果。在 M1 芯片的 MacBook Pro 上测试同一张图，一次图像调色的时间大概可以降到 200ms 左右。
第五阶段：结构设计与 JNI 集成
这一功能之前就做好了，之前在 JNI 层定义了三个核心接口：
JNIEXPORT jlong JNICALL Java_cn_netdiscovery_monica_opencv_ImageProcess_initColorCorrection(JNIEnv* env, jobject,jbyteArray array);JNIEXPORT jintArray JNICALL Java_cn_netdiscovery_monica_opencv_ImageProcess_colorCorrection (JNIEnv* env, jobject,jbyteArray array, jobject jobj, jlong cppObjectPtr);JNIEXPORT void JNICALL Java_cn_netdiscovery_monica_opencv_ImageProcess_deleteColorCorrection (JNIEnv* env, jobject, jlong cppObjectPtr);其中：
- initColorCorrection：负责从 Java 层传入原始图像字节数据，构造 ColorCorrection 实例并返回 native 指针（jlong）colorCorrection：执行调色功能，接收设置参数对象与指针，并返回处理后的像素数组。deleteColorCorrection：释放 native 对象，防止内存泄漏。
随着功能不断增多，初期所有 JNI 实现集中在一个 cn_netdiscovery_monica_opencv_ImageProcess.cpp 文件中，逐渐变得难以维护。于是我将其按功能模块进行拆分，形成结构清晰的目录布局：
jni/├── cn_netdiscovery_monica_opencv_ImageProcess.h # jni 对应用层暴露接口的头文件，主 JNI 注册入口├── cn_netdiscovery_monica_opencv_ImageProcess.cpp # jni 对应用层暴露接口的源文件└── color_correction/ ├── jni_color_correction.cpp # 调色 JNI 实现 └──color_correction_internal.h # 调色 JNI 实现头文件总结
这次图像调色功能的优化过程，是一次典型的工程实践驱动优化：从最初直观易写的forEach实现，到逐步引入并行处理与数据复用、 LUT 表查表，再到结构层面的模块拆分与 JNI 封装，每一步都力求在效果一致性、性能提升、架构清晰之间找到平衡。最终实现了从"能跑"到"高效可维护"。
当然，这并不是终点。如果未来 Monica 要支持更高分辨率的图像、实时滤镜预览等等，还有一些明确的优化方向值得深入探索：
引入 OpenMP 或 TBB当前使用的 parallel_for_() 已具备良好并行性，但在控制粒度、任务分配、线程亲和性方面还有提升空间。结合 OpenMP 或 TBB 可实现更高效的多核调度。
使用 SIMD 指令集（如 SSE、AVX、NEON）进一步加速在性能关键路径（如像素变换、掩码混合、色彩映射）中使用手写或自动矢量化的 SIMD 优化，有望将瓶颈段加速数倍。
最后，本次优化的代码，可以在这里找到: github.com/fengzhizi71…另外，图像编辑器的地址：github.com/fengzhizi71…
