如何在FirstLightImaging C-Blue One相机回调API下兼顾高采集帧率与实时显示

我正在使用FirstLightImaging C-Blue One相机和模拟电压执行器搭建闭环系统，通过计算图像偏移向执行器反馈实现稳定控制。系统核心功能正常，但实时图像预览会拖慢核心采集帧率。参考@dan-mašek的Stack Overflow思路，我计划分离采集、图像处理和执行器反馈线程（目前执行器反馈线程已独立）。

相机输出768×768分辨率图像，我们会将其合并（bin）为256×256用于偏移计算，但当前使用的快速合并函数会破坏原始图像，导致无法显示768×768的原始画面。

相机提供回调API，要求回调函数（接收uint16_t*参数）必须在1.52ms内完成操作，才能维持655FPS的采集帧率，否则会丢帧。当前回调函数在采集线程中执行以下操作：

• 图像合并（耗时0.34ms）
• 图像预处理：均值减法与平场校正
• 计算偏移（耗时0.3-0.4ms）：正向FFT、与参考图像FFT共轭相乘、反向FFT
• 插值法计算亚像素偏移
• 向执行器反馈线程发送就绪信号

以上1-4步总耗时0.8ms，符合时间要求。但目前每32帧显示一次（约20FPS），若改为每16帧显示一次（约40FPS），采集帧率会降至627FPS；把显示窗口改成512×512时，采集帧率也会降到约640FPS。而相机原厂软件能在维持655FPS采集的同时实现50FPS实时显示，说明该目标可达成。

当前通知显示线程的代码：

if (!(curr_count & ((1 << 5) - 1))) {
    unique_lock<mutex> dul(displayMutex);
    displayReady = true;
    dul.unlock();
    displayConditionalVariable.notify_one();
    dul.lock();
    displayConditionalVariable.wait(dul, []() { return !displayReady; });
    dul.unlock();
}

显示线程代码：

DWORD WINAPI displayThread(LPVOID lparam) {
    cv::Mat img;
    double *image = (double *)lparam;
    cv::namedWindow("Live!", cv::WINDOW_NORMAL);
    cv::resizeWindow("Live!", 256, 256);
    while (true) {
        unique_lock<mutex> dul(displayMutex);
        displayConditionalVariable.wait(dul, [](){return displayReady;});
        displayReady = false;
        dul.unlock();
        displayConditionalVariable.notify_one();
        const cv::Mat img(cv::Size(NX, NY), CV_64FC1, image);
        cv::imshow("Live!", img);
        cv::waitKey(1);
    }
}

核心问题：如何在不降低相机655FPS原始采集帧率的前提下，实现约40FPS的512×512窗口或768×768原始分辨率实时显示？

1. 保留原始图像数据，避免采集线程修改原始帧 #

不要在采集线程的回调函数中直接修改原始uint16_t*图像数据做合并操作：

• 在回调函数中，先将原始768×768图像数据完整拷贝到一个独立的缓冲区（建议用线程安全的环形队列，容量至少预留3-5帧，防止短时间内显示线程处理不及时导致丢帧）。
• 合并、预处理等计算操作，在单独的图像处理线程中对拷贝后的帧数据进行，这样原始帧数据可完整保留给显示线程使用。

2. 重构采集与显示线程的同步逻辑，消除采集线程阻塞 #

当前代码中采集线程通知显示后会等待显示完成，直接占用了采集线程的宝贵时间，是帧率下降的核心原因：

• 改成单向通知+无阻塞模式：采集线程每16帧（对应40FPS）将原始帧拷贝到显示队列后，立即返回继续处理下一次采集，完全不等待显示线程的处理结果。
• 显示线程独立从队列中获取帧数据，处理显示逻辑，所有操作与采集线程解耦，不会抢占采集线程的CPU时间。

3. 优化显示线程的图像处理效率 #

• 提前分配好显示所需的cv::Mat对象，避免每次显示都重新创建：比如提前创建768×768的CV_8UC1格式Mat（用于将16位原始图像转换为8位显示格式），以及512×512的缩放后Mat，每次仅更新数据即可。
• 缩放操作（768×768转512×512）选择高效的插值算法：优先用INTER_NEAREST（速度最快），若对画质有要求则用INTER_LINEAR；如果硬件支持GPU，可启用OpenCV的CUDA加速模块（如cv::cuda::resize）进一步提升缩放速度。
• 保留cv::waitKey(1)确保窗口响应，但无需额外增加延迟，避免占用过多CPU资源。

4. 实现高效的线程安全帧队列 #

• 用std::queue配合std::mutex和std::condition_variable实现环形队列：当队列不为空时，显示线程才会唤醒取帧，避免空轮询消耗CPU；当队列满时，采集线程可覆盖最旧的帧（保证显示的是最新画面）。
• 若追求极致性能，可使用无锁队列（如基于CAS操作的实现），减少锁竞争带来的开销。

5. 调整线程优先级，保障采集线程资源 #

• 将采集线程的优先级设置为最高（Windows下用SetThreadPriority设置为THREAD_PRIORITY_HIGHEST），确保在系统资源紧张时，采集操作不会被显示线程或其他低优先级线程抢占CPU时间，维持655FPS的采集帧率。

内容的提问来源于stack exchange，提问作者Harsh M